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

Reply via email to