The way we've been working in 1.x being major releases with minor releases (1.X.Y) for major bug fixes (occasionally rolling in minor improvements with said bug fixes). We've been running a ~6 month dev cycle per release which is flexible as features come.
Personally, I think this method has worked well for us and I see no reason to mess with it. John ----- Original Message ----- | From: "Jesse Yates" <[email protected]> | To: [email protected] | Sent: Monday, October 31, 2011 11:48:27 PM | Subject: Re: Branching | I'm okay with branching the current trunk into 1.4. | | Here is the link to the current issues for | 1.4<https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+ACCUMULO+AND+fixVersion+%3D+%221.4.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide> | | My only concern is how the numbering for releases works. Is it that | odd is | dev and even is public release? Or are all 1.X considered public | releases | and then 1.X.Y is the minor dev release? We probably should establish | our | plans on this so we have a community standard for doing the versions | (though we can always change it later. | | --Jesse Yates | ------------------- | Jesse Yates | 240-888-2200 | @jesse_yates | | On Thu, Oct 27, 2011 at 10:38 AM, John W Vines | <[email protected]>wrote: | | > There has been some discussion about branching 1.4. There have been | > some | > rounds of testing done against a few iterations and we're trying to | > wind it | > down so we can be prepared for release. Unofficially we've been | > operating | > under a semi-feature freeze to avoid larger disruptions to the | > testing. For | > the sake of openness though, we seriously need to formally declare a | > feature freeze. I feel the best way to do this is to branch 1.4, | > this way | > 1.5 feature development can continue while we root out large scale | > testing | > bugs in the 1.4 branch. | > | > Mentors- How long is an appropriate time to wait between announcing | > and | > carrying forward with branching? Should we put it up to vote or is | > simply | > no one objecting to branching within the timeframe sufficient? | > | > Everyone- I think we've done a fairly good job labeling tickets as | > to | > whether they're 1.4 or 1.5. There are still some tickets which are | > marked | > 1.4, I think, which could/should be pushed on to 1.5 instead of | > holding | > back 1.4. In case of this, please open up discussions on the tickets | > so we | > can come to a decision on a case by case basis. There are a few | > items of | > discussion, particularly | > https://issues.apache.org/jira/browse/ACCUMULO-74and | > https://issues.apache.org/jira/browse/ACCUMULO-19 which both involve | > packaging of Accumulo. I feel the best way to deal with these | > tickets in | > 1.4 is as follows- | > | > If the packaging for them is done before we do the final update for | > 1.4 | > (which we will determine after sufficient testing of the frozen | > product) | > and they do not interfere with standard operating procedure, I think | > we | > should include them in 1.4 as the impact of these pom changes is | > very small | > but the impact could be large. However, I don't think we should be | > left | > waiting for these changes if they are the only things left. | > | > | > Please discuss! | > | > John | >
