Ubuntu Monthly Update Cadence Proposal
bryan.quigley at canonical.com
Fri Feb 2 16:55:05 UTC 2018
> Stability means: no changes in functionality.
Ah, this is the key point of my proposal. Stability for my purposes
means predictability when changes in functionality will occur.
> 4. Apt is geared towards advancement, not retreat. Meta packages can't be
> used to uninstall, and rarely to downgrade. Any component grouping would
> benefit from being real atomic entities that can be removed as a whole as
> 5. My main point is that components could introduce new apt jargon in the
> sense that:
> "apt groups" would list all components
> "apt list <group>" would list the packages for that component
> other apt commands remain the same, but might have slightly different
I did consider that parts of this proposal might be easier in snaps,
which would be a bit more like you describe.
I tried to limit to items that we could test for a 6 month period of time.
> Additionally with respect to point 4, I think it is essential that people
> can also downgrade to a previous 'Monthly'.
> This means that all the library versions of that monthly still have to be
> available in the repos essentially creating 'frozen' sets for each month.
> Also, if meta packages (or new "groups") pull in the upgrades they must be
> specified on exact versions so that pervious meta packages can downgrade
> what was upgraded.
> Ie. the meta package "monthly-latest" pulls in "monthly-18.10.4", with
> "monthly-18.10.4" pulling in the changes, but "monthly-18.10.3" would be
> able to undo all of that.
> This would imply that those monthly metas do not only indicate what they
> upgrade, but also what they didn't upgrade.
> The monthly metas then indicate the exact versions of all core components.
Then we have monthly releases, I specifically didn't want to do that.
Obviously it's something that could be considered instead though.
> As an additional colloquium:
> Core components might also need to specify ALL libraries being pulled in
> by their upgrade, and might require those libraries to be split off into
> components of their own if these libraries are shared between core
> At the same time this creates inflexibility; you cannot keep using an
> older version of udev if it breaks some device.
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
More information about the Ubuntu-devel-discuss