I would like to declare end of life for the 1.4 branch of development. It's been active for a little over two years and the release of 1.6.0 means we now have three active releases.
Declaring end of life would mean
* Posting an ANNOUNCE message to the user list * No longer accepting issue fix version targets for future 1.4 releases * Removing fix version targets of 1.4.x for existing open issues * The end of having a long lived 1.4 related branch in git * Removing direct references to 1.4.x releases on our download page * No longer linking to the 1.4 related documentation from the main navigation area
Our issue tracker shows that candidate version 1.4.6 currently has:
* 9 closed issues, none of which are blockers or critical. * 1 issue in patch available status, marked critical * 18 open issues with a target fix version of 1.4.6, four of which are marked critical.
Because there is existing work, but not yet enough to warrant a release, I propose that on successful passing of this vote we create a "1.4.6-eol" tag with the then current state of the development branch.
[ ] +1 I am in favor of announcing End of Life according to the above plan [ ] +-0 I am indifferent [ ] -1 I am opposed to the above End of Life plan because...
I'm treating this like a release vote. Thus, it will be handled with Majority Approval: to pass it will need 3 committers to +1 and more committers voting +1 than -1.
Vote will remain open for 72 hours, until Tuesday, May 6 2014, 20:40 UTC
-1 because I suggest the 1.4-related documentation remain on the site. I believe existing users of 1.4 will not be moving to 1.5 for a long time. So the same reason, I think the release download link should remain for the same reason.
Does EOL mean the releases will be removed from official maven repositories? On Sat, May 3, 2014 at 4:41 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
I purposefully only included not linking to the docs from the main nav menu, because I also think the docs should stay online, at the same URLs.
I haven't been keeping up with the website redesign, so I didn't want to get caught up in specifics of how we might get people to them. Provided there's some place we can add an "older documentation" section of links, would that address your concern?
Nonactive release are always available for download form the archive, which is linked at the bottom of the releases page.
The main point of the downloads page is to draw people to versions we want them to use, so I'd rather restrict 1.4 to the archive. Is your concern that people have a way to get to the 1.4 artifacts or that they be prominent?
Once artifacts have been posted to the apache maven repository they should be available indefinitely, so we would not remove any 1.4 related ones.
Sean On May 3, 2014 4:01 PM, "David Medinets" <[EMAIL PROTECTED]> wrote:
Overall, in favor, but... 1. Confusing tag name 2. Alt. Option 1: just drop the active dev branch, no tag 3. Alt. Option 2: just closeout 1.4 with a quiet administrative 1.4.6 source release 4. Voting under "release" rules is invalid without signed release artifacts
Overall, I'm in favor of EOL'ing 1.4.x, but I'm not sure what an "1.4.6-eol" tag in SCM would mean to users. The "-eol" suffix couldn't really be documented anywhere for users to understand how that would differ from an actual release/tagged version, for users browsing the SCM tags. I understand a tag is not a release, but to a user, that may not be clear. It's also very confusing, because it does look like an updated release... it has a 1-up version number over the last release (1.4.5), after all. That's very confusing.
To alleviate the confusion, it may be better to call it "1.4-eol" or something else to indicate that it's not a newer release than 1.4.5 (it's not a release at all).
An alternative option to the 1.4.6-eol tag: just drop the development/planning branch. (This is the option that was exercised when this decision was made for 1.3.x). All the relevant code is merged to newer branches anyway, and the outstanding work planned for a future 1.4.6 which will never come to pass is not useful to tag distinctly. Besides, the HEAD commit of 1.4.6-SNAPSHOT will be around indefinitely, as it's merged to master, so we could achieve a similar purpose by simply noting its current HEAD commit [5bd4465c433860624091b0d97892e02f58154e7a] in a message to the mailing lists, for archival purposes.
Another option: do an actual release vote on a signed 1.4.6 source artifact. It wouldn't be hard to pass, since 1.4.5 passed, and the current state of the branch isn't substantively different. We could just call this an administrative release... no need for release announcements and such, but it would clear up the name confusion. 1.4.6 would be an actual thing at that point, voted on and approved for release.
You can't issue a vote under our rules for releasing without providing release artifacts on which to vote. While it may still be valid to have a similar voting mechanism for this kind of thing, what you're proposing is certainly not a release vote. And given that I can see arguments for treating it as a release plan cancellation[majority], though... or code change[lazy consensus]... or even adoption of new code base[consensus], I think the bylaws may need some clarification on EOL procedures/voting.
Responses inline On Sun, May 4, 2014 at 12:50 AM, Christopher <[EMAIL PROTECTED]> wrote:
I would really like to avoid doing a 1.4.6 release unless someone both feels strongly about the need and is also willing to shepherd through the testing process. The issues closed against it to date don't add substantively to the 1.4.5 release enough to justify the time investment in testing, IMHO.
I would be fine with either dropping the tag entirely or using something like 1.4-eol. I am inclined to have a tag we can refer to in any announcements, because they are easier to deal with for casual developers.
Presuming no one wants to volunteer to handle a 1.4.6 release, could we handle the tag naming as a follow-on action since it is just a code change?
My apologies for the lack of clarity. I only meant the phrasing "treat like a release vote" to convey the relative importance I give the topic and to offer some reasoning on why I was looking for stronger committer buy-in than simple lazy approval. I did not mean to imply that this actually *is a* release vote.
I agree that the bylaws as they stand could use clarification on EOL. However, I think planning would go smoother for our users if we incorporated EOL timing and procedures into a defined lifecycle for major versions rather than leaving it as an independent voting action. Since this is part of a larger, more involved topic would you be fine with having it handled as a part of our discussions around the 2.0.0 version change rather than tying up the sunset of 1.4?
Having a plain "1.4.6" release would be nice (I don't like the "-eol" tag), but I'm fine with any other plan that closes out 1.4 with a modicum of clarity for users - for example, a tag off which someone could fork and carry on development if they care to.
I can assist with adjusting the site after EOL with moving doc links etc.
Bill H On Sun, May 4, 2014 at 4:04 PM, Sean Busbey <[EMAIL PROTECTED]> wrote: // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
If the intent is to treat the tagging as a separate action from this plan, then my vote changes to +1 for this plan.
I have no objection to just dropping the branch (and mentioning the HEAD commit in the mailing list, in case the branch needs to be resurrected for some reason). My -1 comes from the "-eol" tag, not the rest of the plan. I don't see value in creating that tag, and worry about its potential for confusion.
Have to be careful w/ deleting the 1.4.6-SNAPSHOT branch and storing the commit hash externally to git. If nothing refs (no other commit, tag, branch, etc) that commit hash, then it could be gc'ed by git. On Mon, May 5, 2014 at 11:42 AM, Christopher <[EMAIL PROTECTED]> wrote:
What already committed development in the 1.4.6 line do you find compelling for a release?
Is there a different tag name we can use as a place holder for "look here if you want to work with the last of the 1.4.x development" that you think will be clearer for users? (and presumably not quite so long as that quoted expression)
On Mon, May 5, 2014 at 11:11 AM, Keith Turner <[EMAIL PROTECTED]> wrote: Sean
I think the initial tag that's included in the vote would have to occur (presuming the vote passes), but any follow up action based on that tag (deletion, rename, etc) would just be a code change, so we could quickly correct things.
While this is practically the same as handling the tagging differently, there would be a brief point-in-time where the -eol tag would exist. Is that okay?
-Sean On Mon, May 5, 2014 at 10:42 AM, Christopher <[EMAIL PROTECTED]> wrote: Sean
Removing a tag will not necessarily remove it from mirrors, but it depends on how it is being mirrored. A git remote prune, for instance, will not remove tags.
Further, if removing a tag can be done as a "code change", which requires consensus (lazy, but still consensus), not majority, then creating the tag should also be considered under those same terms, right? Clearly, creating this tag does not have consensus.
At the risk of flip-flopping, I'm going to have keep a -1 vote for this release plan if it includes the creation of this confusing tag name. I really think just dropping the branch is sufficient.
On Mon, May 5, 2014 at 12:36 PM, Sean Busbey <[EMAIL PROTECTED]> wrote: Good point. I just took a quick look in Jira and I do not see anything that I think is compelling ATM. Would not want to release as is. I am leaning towards Christophers suggestion of not having a tag and recording the commit hash on the mailing list.
Ok. I did not check if another commit referenced it. My main concern is if this becomes SOP for EOL, then we should be careful to ensure the commit hash is referenced. On Mon, May 5, 2014 at 1:24 PM, Christopher <[EMAIL PROTECTED]> wrote:
I am opposed to the tag, because I think what it communicates to users is confusing. I'm in favor of what Christopher suggested.
I was undecided about the general concept of 1.4 EOL, I am still working w/ some users who are still using 1.4 in the short term. Should they run into a serious bug, we will very likely fix it. I discussed this situation w/ Christopher and he suggested if this situation were to occur we could simply post a patch jira. That plan sounds good w/ me and makes me comfortable w/ 1.4 EOL now. On Sat, May 3, 2014 at 4:41 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
I elaborated above, but in short, all previous tags have indicated releases. This is standard to publish tags in SCM to denote a release. it's confusing to have a tag that does not denote a release. Further, having a version that is greater than the greatest approved release may mislead people who build from source to use the "latest", thinking it was approved and it wasn't.
As far as 1 is concerned, I have the sense that there's general consensus that we should de-emphasize the 1.4 releases in favor of 1.5 at this point. We could go far in doing this by changing the wording on the website:
Current Stable Release: 1.5.1 Legacy Bugfix Release: 1.4.5
I think we also agree that removing Maven artifacts is out of bounds because that will cause breakage for all sorts of things. Mirrors will likely want to drop release tarballs at some point (e.g for old point release versions like 1.4.3, 1.4.4) but I'm not sure how they are signaled to do so. I'm generally in favor of keeping the documentation for old versions around. (E.g: you can still find docs for Lucene 3.0.3 at Apache and it's ancient!)
I don't think it makes sense to tag a 1.4.6 release until someone is prepared to follow the release process and produce votable artifacts. At this point I'm hearing that a) work isn't done and b) there isn't sufficient reason to create 1.4.6. I don't think that there is any onus on the Accumulo community to ever produce a 1.4.6 release, but we should not do anything that will prevent that from happening or make it difficult to do so. There are still folks out there that are using 1.4 actively and who knows what darkness lurks at the heart of Accumulo that might need to be fixed.
Could someone explain why we would want to ever delete the 1.4.x branch?
So, in summary:
1) I agree it makes sense to clearly market 1.5 as the current stable release and market 1.4 as something old that you only want to start using if you're already using. 2) I can't see any good reason to do anything with tags or branches at this point.
It is not clear to me why we would want to do anything in SCM to eol 1.4, as long as we cover the website. I'm interested if there are specific mechanical reasons.
Drew On Mon, May 5, 2014 at 3:01 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
No, the veto on tag creation would not halt a release. A release is the source artifact. I can't imagine anybody would veto creation of a tag to denote the branch from which that artifact was made, though. In any case, I agree it's not a code change... it's a procedural step. I was questioning it as a code change, since busbey indicated deletion of a tag would be one.
* that it's the major version 1.4 (which should limit our ratio of closed-branches to total tags) * that it's not a release * reasonably well that it's the end of a development branch without an explanation on the website
On Mon, May 5, 2014 at 2:38 PM, Christopher <[EMAIL PROTECTED]> wrote: Sean
On Mon, May 5, 2014 at 3:38 PM, Christopher <[EMAIL PROTECTED]> wrote:
I agree that 1.4.6-eol is not a good name since it implies a 1.4.6 release that never happened.
I don't agree with the fact that tags are only used in SCM to denote a release. I think that's the most common usage, but I've always viewed a tag as any significant point on a branch that signifies not to expect further changes. The places where those exist in most projects is for releases and branches that have been EOLed.
On Mon, May 5, 2014 at 3:40 PM, Drew Farris <[EMAIL PROTECTED]> wrote:
There is also the impact on ticket workflow. When a version is EOLed, I'd not expect the community to provide any additional fixes for that release line. If 1.4 hangs around, then it creates confusion over what will happen to tickets filed against it. It also will confuse users as they may keep filing 1.4 tickets. Agreed. We used to have something like this, but that lead to some arguments over which is stable and which legacy. For example, 1.6.0 is out now so that means that there would be three releases we need to identify. Absolutely. We should never delete released artifacts. I think you want to delete the branch because of our Git workflow which is to always target a patch for the earliest, non-end-of-lifed version. You could argue that the documentation and mailing list announcement are sufficient to declare the branch EOLed, but I don't think that's strong enough for a casual contributor.
The purpose of the EOL is to say that the community *won't* create a new 1.4 release. If you need to stick with it for whatever reason, it's expected that you and/or your support vendor will backport required patches and cut your own releases. Nothing here will prevent that. In fact, creating the tag for the work that was in progress on the 1.4 line post the 1.4.5 release should make that easier. -Joey
On Mon, May 5, 2014 at 3:58 PM, Joey Echeverria <joey+[EMAIL PROTECTED]>wrote: .6 is part of what was causing me heartburn. I suppose another part is what the tag communicates. However, this can easily be solved w/ a section about tags on web site in the git docs.
With an accompanying definition on our website, I would be ok simple tag like : 1.4-eol. The web site could define that tags matching this pattern reference unreleased commits for a branch on which we will no longer do releases..
It sounds as if there's agreement on a number of points and it sounds like I'm the only person not in favor of deleting the branch and creating a tag a this point. Also, bug management is an interesting issue. Thoughts in-line below:
On Mon, May 5, 2014 at 4:07 PM, Joey Echeverria <joey+[EMAIL PROTECTED]>wrote: If people find ticket-worthy issues in 1.4 after it's end-of-lifed wouldn't we expect them to file a ticket against that version? Shouldn't these tickets reflect known issues with a release of software that people use? Regardless of the desire of the development community to produce new releases of a specific branch, it is a service to the community of users to be able to record known issues (even if these will ultimately result in a wontfix resolution). Google does a very good job indexing the Apache JIRA.
Furthermore, issue reporting activity is a reflection of real-world use which should naturally migrate to future versions, and if people aren't migrating to future versions, we have bigger fish to fry.
> To something else, perhaps:
Ok, so, we list three releases instead of two. Two of them happen to be considered stable. If there's confusion in the user community, we likely need to do a better job explaining which one to use a la tomcat 
Current Stable Releases: 1.5.1, 1.6.0 Legacy Bugfix Release: 1.4.5 I think you want to delete the branch because of our Git workflow
Who are we trying to protect here? and what are we trying to protect them from? If casual contributors can't keep up with the current state of the code and repository via the mailing list or website, I'd worry either about the quality of their contributions or the quality of the documentation the community is producing in terms of the current state of the project. If folks that would commit to the project aren't aware of where merges should be made I'd worry that they shouldn't be committing to the project in the first place without guidance from the community.
So, to summarize:
I agree it's time to end of life 1.4 in that I'm in favor of stating clearly that users should not expect new releases of 1.4.x and new projects and migrations should use some other version (preferably 1.6.0)
I'm against stating that a new release of 1.4 will >never< be made or must branch in favor of a tag.
I'm also not in favor of preventing people from documenting the issues they find with 1.4 as tickets in jira.
I share your concern about stating that a new release of 1.4 will *never* be made or *must never* be made, but I don't see how that affects removing of the branch for active development. If an issue warrants it, that branch can always be reopened. Removing it indicates that it's not expected to be reopened, and that we've agreed to focus on new versions.
I also have no problem reporting issues in JIRA as affecting the version they are using. However, we really want to focus on bugs that still affect a supported version, so a report against an older version that does not also affect a newer one isn't very useful for issue management. I'm not sure if that means we should archive the 1.4.x versions in JIRA, so people can mark those versions as affected or not. Maybe it'd just be useful to just archive 1.4.0-1.4.3, and leave 1.4.4/1.4.5 unarchived. (I suggest the last two versions of 1.4, only because the last version introduced a lot of changes that people may be reluctant to update to, if they aren't transitioning to hadoop 2).
On Tue, May 6, 2014 at 8:53 AM, Christopher <[EMAIL PROTECTED]> wrote: I don't like removing branches because forces those folks who are maintaining their own 1.4 branches to figure out how to fix things locally when the remote branch they're tracking goes away. Is it sufficient to tell folks to do the following to address this?
git rebase --onto 1.4.6-SNAPSHOT-eol 1.4.6-SNAPSHOT 1.4.6-SNAPSHOT-local
What happens if the branch is deleted and then is reopened at a later time? Are there further machinations that a developer maintaining a 1.4.x branch much go through to get back on track?
Perhaps this is just the way with git, and I'm trapped in the mindset of long-running branches that run parallel to major revision development and aren't targeted at a specific point release. In looking at this I'm reminded that the Accumulo community has chosen the latter path where branches are short-lived and targeted at the next release.
I see JIRA being useful as both a work tracking/planning tool >and< a user support tool / record of project history (like commit history). Would archiving releases prevent historic issues from being findable via google?
Replies in line. On Tue, May 6, 2014 at 7:34 AM, Drew Farris <[EMAIL PROTECTED]> wrote: If we archive the version in Jira, it will not allow people to use that version as Affected or Fix when modifying tickets (though it will leave previous tickets in place).
This means that people filing an issue against 1.4 would have to leave this field blank (or preferably state a non-archived version it also impacts) and then mention that it impacts 1.4 in the environment or in the description.
We could wait some period of time to archive the version and declare that time period on the mailing list (say 6 months or 1 year). However, that's a slippery slope. At what point do we stop waiting for issues to be filed? Why did we archive 1.3.x?
This is a bad idea. We have the archive for a reason. We even say "if you're looking for an older release, here's the archive." We can't keep every major branch prominent forever.
Regardless of the current situation around a certain user base sticking with the 1.4 branch, as a community our recommendation is that people not use that version. Right? Or are we not in agreement on this? For the record, no one is saying "never"; we're saying "probably not". It would take a significant error (say a critical security flaw) along with a user asking for us to have another 1.4 release after end-of-life. The same goes for 1.3, as far as I'm concerned.
The biggest impact of that change means we stop looking for things to fix in 1.4.
replies inline On Tue, May 6, 2014 at 8:21 AM, Drew Farris <[EMAIL PROTECTED]> wrote: Yes, I'd say your workflow is just at odds with our branch-and-merge strategy. The work is no different then what you'd have to do when we cut a release and the branch changed from 1.4.5-SNAPSHOT to 1.4.6-SNAPSHOT.
Hopefully with the compatibility focus changes in 2.0.0, you'll be seeing more obviously short lived minor version branches that reappear briefly for bugfix and this will be more obvious. Tickets that only impact archived versions remain in Jira, e.g. ACCUMULO-661 that only impacts the 1.3 line and they are still searchable in major search engines.
Because Jira stops accepting archived versions in autocomplete fields, you can't use the simple search to find all tickets that impact a particular archived version, but you can use advanced search. Once you have completed an advanced search, you can actually switch back to basic and things will work (though it will warn you that your version choice is invalid).
I'm +1 with the stipulation that I'd like the end of life marker tag changed to be 1.4-development-closed (or whatever similar phrasing we have consensus on). On Mon, May 5, 2014 at 3:02 PM, Christopher <[EMAIL PROTECTED]> wrote: Sean
Archiving versions in JIRA simply remove them from the drop-down list of options when filling in the "Affects Version". Similar to releasing a version in JIRA means it is removed from the drop-down list of options when filling in the "Fix Version".
I want to EOL 1.4.x but I am having difficulties following this discussion. If someone could provide a tldr; I will probably change my vote. On Tue, May 6, 2014 at 12:31 PM, Ryan Leary <[EMAIL PROTECTED]> wrote:
Changing vote to +1 w/ caveat that we drop .6 from tag name. ok w/ any of the alternate tag names that have been proposed On Tue, May 6, 2014 at 12:22 PM, Joey Echeverria <joey+[EMAIL PROTECTED]>wrote:
+1 for EOL'ing 1.4. -0 for any follow on actions. I don't see any particular value in doing anything beyond just not contributing to the 1.4 branch any more. On Tue, May 6, 2014 at 2:45 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
+1: David M, Josh E, Bill H, Sean B, Keith T +1 (non-binding): Joey E, Ryan L, Alex M +0: John V -1: Christopher T
Thanks everyone for participating. I'll take care of implementation later this evening. On Sat, May 3, 2014 at 3:41 PM, Sean Busbey <[EMAIL PROTECTED]> wrote: Sean
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