accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Farris <drew.far...@gmail.com>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Mon, 05 May 2014 19:40:09 GMT
I suppose this will be a problem we will encounter with every major/minor
revision as they age, so we have a good chance to hash out a general policy
for this.

I see two categories of actions proposed here:

1) Content Changes (e.g: website)
2) SCM Changes (e.g: git repo)

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:

From:

Latest 1.5 release: 1.5.1
Latest 1.4 release: 1.4.5

To something else, perhaps:

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 <keith@deenlo.com> wrote:

> -1
>
> 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 <busbey@cloudera.com> wrote:
>
> > Accumulo Folks,
> >
> > 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.
> >
> > Please vote
> >
> > [ ] +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
> >
> > --
> > Sean
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message