As part of our transition to better versioning standards, and more regular releases, with better release planning, I was thinking that our development branches should generally reflect an anticipated minor/major release version, and not an expected bugfix version. It seems to me that we should focus active development on minor/major releases, and branch for bugfix releases temporarily, only to push out an important bugfix.
With that in mind, I'd like to change the current 1.6.1-SNAPSHOT to 1.7.0-SNAPSHOT in expectation for a forthcoming minor release (we would have to discuss what kinds of things we'd want in such a release. Minimally, I want ACCUMULO-1691), and the master branch to 2.0.0 for development on the next major release.
If there's any outstanding bugfixes in the 1.6.1-SNAPSHOT branch that would warrant a separate bugfix release, I think we should discuss them and plan for a 1.6.1 within a month or so (along with a 1.5.2).
I'd like to discuss this here a bit and see if this makes sense before initiating a vote on it.
I'm thinking the low-impact ones aren't really worth releasing a bugfix version for 1.6.1. They can be rolled up and included in a minor release. I figure 1.6.1 can wait until we find a "you really should patch this if you're using 1.6.0" kind of bug, vs. the "this isn't serious, but you might find it annoying to deal with" kind of bug.
On Mon, May 12, 2014 at 10:08 AM, Alex Moundalexis <[EMAIL PROTECTED]> wrote:
My read is that if there were issues fixed in 1.7.0-SNAPSHOT that would warrant a 1.6.1 release, then a new branch would be made, those issues would be fixed in the branch, and then a release would be cut. Basically, this would change from having long-lived bug fix branches to just-in-time branches specifically for a bug fix release.
I like this plan overall. I am definitely in favor of more frequent, lighter-weight bugfix releases. We can start to move toward a regular schedule of them, based on whether there is enough there to warrant one each month / two months / whatever.
We could start by branching off 1.6.0 now, and merging in whatever bug fix commits make sense (pending a discussion as Christopher suggested). It can be kept in a ready-to-release condition, for whenever it's "time" for 1.6.1.
What about 1.5.x? That will still receive feature changes as well as bug fixes, I assume, until it goes EOL. On Mon, May 12, 2014 at 10:44 AM, Josh Elser <[EMAIL PROTECTED]> wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
Why eliminate the 1.6.1-SNAPSHOT branch for 1.7.0-SNAPSHOT? Why not just branch the master and insert a 1.7.0-SNAPSHOT into our workflow after 1.6.1-SNAPSHOT and before master? On Mon, May 12, 2014 at 11:10 AM, Bill Havanki <[EMAIL PROTECTED]>wrote:
Presumably, it would be based on the tag being fixed, and may include commits from the next minor release. I'm not sure exactly how that workflow would go. There may be other workflows, but I was thinking something like:
1. Create a bugfix release plan 2. Branch the latest tag being bugfix'ed 3. Apply commits to fix bugs 4. Test fixes 5. Release bugfix 6. Merge to next minor/major releases in development once released Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 12, 2014 at 10:08 AM, Alex Moundalexis <[EMAIL PROTECTED]> wrote:
Overall, I like this plan. Ideally, it'd be best if we could limit our active branches to major versions and avoid creating major version branches while we still are waiting on a previous major release's last minor release.
Once we've fully transitioned to a new versioning scheme, what do we expect the steady state to be?
How about something like the following:
* We vote on a release plan that establishes a new major version * major version created in jira * wrap up last planned minor release on previous major version * During this time, keep any incompatible patches meant for hte major version in jira * release last minor release of previous major version * create new major version branch, remove previous major version branch * apply patches from jira for new major version
This way we only have one major development branch at a time. When there are new bug fixes that come in for a supported version we can create a short-lived branch off of previous releases. If we're talking about only having Critical+ issues go into bugfix releases, it should be relatively easy to include them for all minor releases in our supported major release(s).
I'd also like us to formally define major version lifecycle when we vote on a new release plan for that major version. It's probably best if the end-of-life is tied to the release of the next major version, so that we have more incentive to avoid rapidly doing many major releases.
There are two other things in Christopher's original message I'd like to discuss, but I'm not sure if they'd be better served in a different thread?
1) 1.7.0-SNAPSHOT in expectation for a forthcoming minor release
I don't think we ever finished the discussion of what to do with 1.x once we have a 2.x out the door. I'd like to reiterate my concern that mixing versioning number schemes in 1.x is confusing. Every other 1.x release in the line has been a major release. It will be very hard to break that expectation.
2) would have to discuss what kinds of things we'd want in such a release. Minimally, I want ACCUMULO-1691
It's my understanding that ACCUMULO-1691 will break wire compatibility, yes? If we're calling 1.7.0 a minor release, I do not want wire compatibility broken in a minor release. If we're planning to only include critical+ issues on bugfixes, then we need to make sure minor version upgrades are low risk.
I know we haven't finished our discussion about what our compatibility statement will cover and I'd like to have it in place before we do a release under a new versioning scheme (wether or not that includes changing the versioning within 1.x). On Mon, May 12, 2014 at 10:10 AM, Bill Havanki <[EMAIL PROTECTED]>wrote: Sean
The goal here isn't just to insert a mechanical change to the SCM and change the workflow. The goal is to try to orient ourselves to provide faster bugfix deliveries on supported releases, while shifting the focus of active development on major/minor releases.
I think Joey hit the point best: the big change would be the shift to short-lived bugfix branches for immediate release and more regular release cadence, and long-lived branches would be for active development on major/minor releases.
The one clarification here is that I don't think we should have a long-lived 1.6.1 branch.
For 1.5.2, I think we should plan a 1.5.2 release soon, and then eliminate the long-lived development branch for 1.5.x, in favor of a short-lived 1.5.x bugfix branches that are oriented around specific bugs (since we have two outstanding supported branches, we'd probably fix the same bug in both and release bugfixes for each together, depending on the release plan put forward by whoever is calling for a release).
On Mon, May 12, 2014 at 12:00 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
I agree that it makes sense to vote on a release plan to establish a new major version. I'm not sure I followed the rest, but I think once a new major version is released, minor releases on the previous major one should stop. But, minor releases on the last released major version can continue until the next major version is released. That would imply one major version (eg. 2.0.0) branch under development at a time, and one minor (eg. 1.7.0) on top of the last major, and bugfix branches only existing in preparation for releasing. I'm not sure I'd add the restriction to "Critical" issues here. I think what would be included in these would be decided by the release plan. That may mean that it includes one critical fix and 5 minor bug fixes, or maybe a roll-up of 20 minor bugfixes. Whatever is decided to be included, it should be done so by enumerating those fixes in the release plan, voted on as a majority vote, according to the bylaws. While we would be diverging from that expectation, we would not be breaking anybody who holds that expectation, so I think it's fine to proceed with minor releases in 1.x until 2.x is released. To clarify, imagine somebody has that expectation... so they aren't willing to upgrade to a minor 1.7.0 release. That's fine, they don't have to. Their upgrade path would only include 1.6.x bugfix releases. However, if somebody does want a particular feature in 1.7.0, we'd only be lowering the bar for them to upgrade, by ensuring it stays more compatible with 1.6.0. I don't see a problem here. I do not believe ACCUMULO-1691 needs to break wire compatibility at all (I bumped the wire version in the patch, to be safe, but I don't think it needed to be bumped). However, I agree we should discuss whether wire compatibility can be broken in a minor release. If we decide it cannot, I think that would have broader negative implications about being able to bump dependency versions in any minor release. We can discuss that in another thread, though.
On Mon, May 12, 2014 at 10:44 AM, Josh Elser <[EMAIL PROTECTED]> wrote:
I see. Wether or not the testing is excessive depends on the bug fixes. We could relax the goal and let decisions be made per release. A possible way to do this would be to not require anything beyond mvn verify AND people can -1 a release if they do not think sufficient testing was done. This makes it easy to make the testing decisions per release using the existing release voting mechanism.
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext