I am certainly in favor of doing a vote for the same.
Along with that, we should likely make some progress on the logistic issues
with doing a release that Andrew raised.
On Tue, Jan 3, 2017 at 4:06 PM, Sangjin Lee wrote:
> Happy new year!
>
> I think this topic has aged quite a bit in the disc
Happy new year!
I think this topic has aged quite a bit in the discussion thread. Should we
take it to a vote? Do we need additional discussions?
Regards,
Sangjin
On Wed, Nov 9, 2016 at 11:11 PM, Karthik Kambatla
wrote:
> Fair points, Sangjin and Andrew.
>
> To get the ball rolling on this, I
Fair points, Sangjin and Andrew.
To get the ball rolling on this, I am willing to try the proposed policy.
On Fri, Nov 4, 2016 at 12:09 PM, Andrew Wang
wrote:
> I'm certainly willing to try this policy. There's definitely room for
> improvement when it comes to streamlining the release process.
I'm certainly willing to try this policy. There's definitely room for
improvement when it comes to streamlining the release process. The
create-release script that Allen wrote helps, but there are still a lot of
manual steps in HowToRelease for staging and publishing a release.
Another perennial p
Thanks for your thoughts and more data points Andrew.
I share your concern that the proposal may be more aggressive than what we
have been able to accomplish so far. I'd like to hear from the community
what is a desirable release cadence which is still within the realm of the
possible.
The EOL po
Thanks for pushing on this Sangjin. The proposal sounds reasonable.
However, for it to have teeth, we need to be *very* disciplined about the
release cadence. Looking at our release history, we've done 4 maintenance
releases in 2016 and no minor releases. 2015 had 4 maintenance and 1 minor
release
Reviving an old thread. I think we had a fairly concrete proposal on the
table that we can vote for.
The proposal is a minor release on the latest major line every 6 months,
and a maintenance release on a minor release (as there may be concurrently
maintained minor releases) every 2 months.
A min
>
>
> Here is just an idea to get started. How about "a minor release line is
> EOLed 2 years after it is released or there are 2 newer minor releases,
> whichever is sooner. The community reserves the right to extend or shorten
> the life of a release line if there is a good reason to do so."
>
>
Thanks Karthik for opening a long overdue discussion on the release cadence
and EOL.
As for the EOL, I think we need to weigh between the benefit for the users
and the maintenance cost for the community. I'd also love to find out what
other (major) open source projects do in terms of the EOL.
Her
Forking off this discussion from 2.6.5 release thread. Junping and Chris T
have brought up important concerns regarding too many concurrent releases
and the lack of EOL for our releases.
First up, it would be nice to hear from others on our releases having the
notion of EOL and other predictabilit
10 matches
Mail list logo
