Differences between revisions 1 and 37 (spanning 36 versions)
Revision 1 as of 2005-01-07 21:42:08
Size: 351
Editor: anonymous
Comment:
Revision 37 as of 2009-03-16 03:32:58
Size: 1608
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Cuurent release method preserved (with some (?) improvements). Only change made is permitting fixing RC bugs in stable even if packages' behaviour or upstream version changes. After sometime of stable release "Really Stable" which has the current policy of stable is released. Note: This proposal doesn't solve the problem on its own, it's somehow higher level than other proposals. Probably some other proposal like FixedReleaseDate is needed as well.
Line 4: Line 4:
yet to be written here.. Proposal:

Current release method is preserved (with some (this is where the other propsals are used) improvements). Only change made is permitting fixing RC bugs in stable even if packages' behaviour or upstream versions change (but doesn't break the rest of the system). Of course this kind of upgrades should be avioded as much as possible and abusing of the opportunity to fix bugs after release must be prevented. After sometime of stable release "Really Stable" which has the current policy of stable is released.
I have, like, 9 months periods of release cycle for "new stable" and 18 months for "Really Stable" in my mind. I suppose this implies FixedReleaseDate. This propasal can be an extension to FixedReleaseDate or other proposals.

Pros:

 * Those who want newer versions of software will benefit from "new stable". They will accept upgrades which change behaviour of a package as long as these are well documented.

 * People who like current stable and > 1 years release cycles will benefit from "Really Stable" more than current stable since the "Really Stable" will have more real life usage testing (in new stable phase).


Cons:

 * Security team will have to maintain two different releases at the same time.

 * Developers will possibly need to do more work for preparing fixes in "new stable" .


See ReleaseProposals for alternatives.

Note: This proposal doesn't solve the problem on its own, it's somehow higher level than other proposals. Probably some other proposal like FixedReleaseDate is needed as well.

Proposal:

Current release method is preserved (with some (this is where the other propsals are used) improvements). Only change made is permitting fixing RC bugs in stable even if packages' behaviour or upstream versions change (but doesn't break the rest of the system). Of course this kind of upgrades should be avioded as much as possible and abusing of the opportunity to fix bugs after release must be prevented. After sometime of stable release "Really Stable" which has the current policy of stable is released. I have, like, 9 months periods of release cycle for "new stable" and 18 months for "Really Stable" in my mind. I suppose this implies FixedReleaseDate. This propasal can be an extension to FixedReleaseDate or other proposals.

Pros:

  • Those who want newer versions of software will benefit from "new stable". They will accept upgrades which change behaviour of a package as long as these are well documented.
  • People who like current stable and > 1 years release cycles will benefit from "Really Stable" more than current stable since the "Really Stable" will have more real life usage testing (in new stable phase).

Cons:

  • Security team will have to maintain two different releases at the same time.
  • Developers will possibly need to do more work for preparing fixes in "new stable" .

See ReleaseProposals for alternatives.