Indeed, sorry
+1; we may need to tweak it going forward, but it's a great staring (or midway)
point
On 08/10/2019, 22:59, "Sankalp Kohli" <kohlisank...@gmail.com> wrote:
Can we please stick to the vote here. We can always change the
documentation as it will evolve over time.
> On Oct 8, 2019, at 2:57 PM, Joshua McKenzie <jmcken...@apache.org> wrote:
>
> It probably warrants a separate discussion about how we version.
>
> Also, robust +1 to what you said here bes and haddad ;)
>
>> On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad <j...@jonhaddad.com> wrote:
>>
>> This has definitely been a confusing topic in the past, I completely
agree
>> Benedict. Glad you brought this up.
>>
>> I'm 100% on board with 5.0 after 4.0.
>>
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith
<bened...@apache.org
>>>
>> wrote:
>>
>>> 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
>>>
>>>
>>
---------------------------------------------------------------------
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
