As a brief side-step on the topic only of versioning (which no doubt will cause
enough consternation), I personally endorse streamlining it. We have not had a
consistently meaningful convention on this, at any point, and we made it even
worse in the 3.x line. There's no real difference between 1.2->2.0, 2.0->2.1,
or 3.0->3.11 and 3.11->4.0; let's admit this and go straight to 5.0 for our
next feature release, with 4.1 our first patch release of the 4.x line.
On 08/10/2019, 21:36, "Scott Andreas" <sc...@paradoxica.net> wrote:
Re: "How can we decide that *all* new features are suppose to go into trunk
only, if we don’t even have an idea about the upcoming release schedule?"
This is a great question. My understanding of the intent of the document is
that new features are generally expected to land in trunk, with an exception
process defined for feature backports. I think that's a reasonable expectation
to start with. But I also agree with you that it's important we evolve a way to
discuss and agree up on release scope - this was the focus of my slides at
NGCC. I would love to discuss this on a separate thread.
Re: “Bug fix releases have associated new minor version.”
"Patchlevel version" might be more in keeping with our current convention.
Re: "We should give users a way to plan, by having EOL dates"
Incorporating EOL dates into our release management / planning is a great
idea.
Would you be willing to rephrase your comments in the form of proposed
edits to the document?
– Scott
________________________________________
From: Stefan Podkowinski <s...@apache.org>
Sent: Tuesday, October 8, 2019 1:22 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
From the document:
General Availability (GA): “A new branch is created for the release with
the new major version, limiting any new feature addition to the new
release branch, with new feature development will continue to happen
only on trunk.”
Maintenance: “Missing features from newer generation releases are
back-ported on per - PMC vote basis.”
We had a feature freeze before 4.0, which showed that people have
different views on what actually qualifies as a feature. It doesn’t work
without defining “feature” in more detail. Although I’d rather avoid to
have this in the document at all, since I don’t think this is getting us
anywhere, without having a clearer picture on the bigger context in
which release are going to happen in the future, starting with release
cadence and support periods. How can we decide that *all* new features
are suppose to go into trunk only, if we don’t even have an idea about
the upcoming release schedule?
“Bug fix releases have associated new minor version.”
So the next bug fix version will be 4.1? There will be no minor feature
releases like we did with 3.x.0/2.x.0?
Deprecated:
"Through a dev community voting process, EOL date is determined for this
release.”
“Users actively encouraged to move away from the offering.”
We should give users a way to plan, by having EOL dates that may be
months or years ahead in the future. We did this with 3.0 and 2.x, which
would be all “deprecated” a long time ago with the new proposal.
Deprecated: “Only security vulnerabilities and production-impacting bugs
without workarounds are addressed.”
Although devs will define their own definition of “production-impacting
bugs without workarounds” in any way they need, I don’t think we should
have this in the document. It’s okay to use EOLed releases and we should
not prevent users from contributing smaller fixes, performance
improvements and useful enhancements for minor feature releases.
On 08.10.19 20:00, sankalp kohli wrote:
> Hi,
> We have discussed in the email thread[1] about Apache Cassandra
Release
> Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> here[3] Please vote on it if you agree with the content of the doc [3].
>
> We did not proceed with the previous vote as we want to use confluence for
> it. Here is the link for that[4]. It also mentions why we are doing this
> vote.
>
> Vote will remain open for 72 hours.
>
> Thanks,
> Sankalp
>
> [1]
>
https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> [2]
>
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Attachments area
> [4]
>
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
>
<https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=gmail#heading=h.633eppni91tw>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
