Oh, and I vote 4.0 for the first apache release. Unless I totally misunderstand something that's what we've been calling it for awhile and I think it will confuse things for outsiders to change now. On Oct 31, 2012 7:16 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
> I just reread this, and it sounds more like we decide what the version > will be (major or minor) AFTER we know what's going into it. I'm OK with > that of course, but we'll need some sort of definition to go by. I also > think it may end up in favor of major revs more often than not. > > We could also do something else like align major revs with target > platforms, e.g. 4.0 targets centos 6.x and Ubuntu 12.04, with minor revs > being feature releases. That may help solidify the support life cycle as > well, and we just rev when the next generation of platforms is chosen and > tested. > On Oct 31, 2012 7:02 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: > >> +1, this would line up nicely with having a major rev once a year with 2 >> or 3 minor revisions in between. >> Then maybe once a month someone rolls up any applicable bugfixes and we >> do a point release? Do we want to have some procedure around that, like a >> mini vote? >> On Oct 31, 2012 6:26 PM, "Chip Childers" <chip.child...@sungard.com> >> wrote: >> >>> On Thu, May 24, 2012 at 10:45 AM, David Nalley <da...@gnsa.us> wrote: >>> > So I think we have consensus around a few things already - lets >>> > highlight those: >>> > >>> > * Time based releases >>> > * Versioning scheme: >>> > X.Y.Z >>> > >>> > - X : increases when there is a "major" change in architecture or some >>> > major new feature >>> > - Y : increases with every release every 6 month (reset when X >>> increases) >>> > - Z : increases when there are "must fix bugs" or annoying bugs that >>> > get fixed in a release branch (reset when Y increases) >>> > >>> > >>> > ===== What we don't yet have consensus on ===== >>> > >>> > * What the time period is on releases >>> >>> Digging this out of the past, IIRC, we never got around to resolving >>> the time period for releases. We should come to a conclusion on this >>> topic! I'd like to propose that we follow a 4 month release cycle for >>> non-bug fix releases. >>> >>> Generally, it would mean a schedule that would look something like >>> this (M=Month and W=Week): >>> M1 through M2 - Features are being developed in branches, and merged >>> into master over the course of these two months >>> M2 W4 - Feature freeze (and release branch is cut). >>> M3 W1 through M4 W1 - Doc Updates and Testing >>> M4 W1 - Docs Freeze >>> M4 W2 - Final regression testing / bug fixes / doc fixes >>> M4 W3 - First RC cut and opened for voting... Wash rince repeat until >>> an RC is voted to be released >>> >>> This proposal might lean a bit heavily towards documentation and >>> testing, but my opinion is that features are going to be developed >>> outside of this release cycle. What matters, is when they land in >>> master, and when they are scheduled to be released. IMO, this type of >>> schedule provides us with the ability to have predictable periods of >>> time for stabilization and documentation. >>> >>> If the actual time period of the release is something other than 4 >>> months, then I would argue for a similar schedule in the ramp up to >>> the first RC. >>> >>> If we can reach a consensus on this, I'll be happy to draft up a >>> schedule with specific dates for our 4.1.0 release. >>> >>> Thoughts, comments, flames? >>> >>> -chip >>> >>> > * What the version number for the first Apache release should be (to >>> > be fair we haven't really discussed this.) >>> > >>> > So lets start with the easy one, the version number - should we target >>> > 3.1.0 or 4.0.0 or something else entirely? I could be swayed either >>> > way. >>> > >>> > On the release time period - as a packager for 20-30 packages in >>> > Fedora I am certainly sympathetic to release cycles, and realize that >>> > virtually all of the community distros (save Debian which is on a two >>> > year release cycle) are on a 6 month cycle. That said I don't know >>> > that we can necessarily be married to what the distros are doing. I >>> > also look at projects like subversion which are tossing out releases >>> > approximately every 60 days - and I don't see any distro that doesn't >>> > carry subversion (though admittedly very different projects in >>> > virtually every respect) I think every 3-4 months makes sense to me, >>> > but again that's just me - gives us a slightly faster iteration but >>> > hopefully not removing towards an unmanageable release cycle speed. >>> > >>> > Another question is - how long do we support any given release >>> > line......e.g. if I embark on 5.2.0 (completely made up version >>> > number, but assuming the above version scheme) how long will I be >>> > guaranteed bugfixes for 5.2.x. Perhaps it's too soon to even ask that >>> > question - we haven't even pushed a single release out, but something >>> > to think about. >>> > >>> > Thoughts, comments, flames? >>> > >>> > --David >>> > >>> >>
