The release is absolutely 4.0.0-incubating. This thread is an old one, which I dug up trying to remember if we picked a release timeframe previously. We had not, as far as I can tell.
- chip Sent from my iPhone. On Oct 31, 2012, at 9:28 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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 >>>
