Update in a world of modules
Last updated at 2:37 pm UTC on 16 January 2006
This page was written for the now discontinued 3.3 version, so the information given here doesn't apply directly anymore. However it contains notes which may be valuable for future efforts.
> Then there is the question of updates in a world of Modules. It seems to me
> natural that each update refers to some module. (di)
Once good enough, I think Deltas would be used instead of change sets, with the uninstall and activate/deactivate, conflict handling features, and so on. (hg)
Change sets untouched
I've decided that I probably won't alter the current change sets code at all. And note that modular source management may be independent to it. There could then simply be some per-module switch to have the old-style changes mech. (and changes file) register changes that are made. In this way one could choose to use .changes or not (hacking yes, when just trying out packages, no). Andrew Black suggested it is a good option to have for few-files delivery.
Kinds of updates
> Updates that change the
> interface of a Module must be dealt with differently from those that don't,
> and additive changes (backward compatible) may be a third case of interest.
I forgot to write that I think this will be hard to do in other ways than manually. Collectors could be responsible for incrementing versions on different decimal levels, perhaps. But someone on the list wrote that the only true version management that works is to require a specific version, figuring out compatible versions and such doesn't work in practice. Actually I can imagine that to be very true.
Repository
> I imagine 'updates.list' becoming structured, or even merged with the whole
> repository mechanism.
I think we could just open "updates" folders in the repository for people to upload into, then the "update collectors" will somehow process them, perhaps by merging them into three/four-decimal releases. Someone noted Debian's system of Unstable (a slightly better name for test pilot), Testing (IIRC, used by test pilots for some time with few complaints), and Stable.
from danielv:
> I like the Debian system (three configurations - unstable, testing,
> stable). This means I choose what configuration I want to update from,
> and then when I update I get -
> Everything that's been released, or
>1018 Everything that's been out there for two weeks and isn't branded as
> having release critical bugs, or
> Everything that's been marked as not breaking anything else in the
> stable configuration.
That sounds like a good conceptual scheme that we would need to translate into practical procedures. Stable might e.g. be single-decimal releases.
