Re: [DISCUSS] Releases after 4.0
Perhaps we could also consider quarterly "develop" releases, so that we have pressure to maintain a shippable trunk? This provides some opportunity for more releases without incurring the project maintenance costs or user coordination costs. Something like a feature-incomplete mid-cycle RC, that a user wanting shiny features can grab, providing feedback throughout the development cycle. On 26/01/2021, 14:11, "Benedict Elliott Smith" wrote: My preference is for a simple annual major release cadence, with minors as necessary. This is simple for the user community and developer community: support = x versions = x years. I'd like to pair this with stricter merge criteria, so that we maintain a ~shippable trunk, and we cut a release at ~the same time every year, whatever features are merged. We might have to get happy with reverting commits that break things. I think faster cadences impose too much burden on the developer community for maintenance and the user community for both upgrades and making sense of what's going on. I think slower cadences collapse, as the release window begins to collect too many hopes and dreams. My hope is that we get to a point where snapshots of trunk are safe to run, and that major contributors are ahead of the release window for internal consumption, rather than behind - this might also alleviate pressure for hitting release windows with features. On 26/01/2021, 13:56, "Benjamin Lerer" wrote: Hi everybody It seems that there is a need to discuss how we will deal with releases after 4.0 We are now relatively close from the 4.0 RC release so it make sense to me to start discussing that subject especially as it has some impact on some things like dropping support for python 2 The main questions are in my opinion: 1) What release cadence do we want to use for major/minor versions? 2) How do we plan to ensure the quality of the releases? It might make sense to try a release cadence and see how it works out in practice revisiting our decision if we feel the need for it. One important thing to discuss with the cadence is the amount of time we want to support the releases. 2.2 has been supported for more than 5 years, we might not be able to support releases for a similar time frame if we release a version every 6 months for example. To be sure that we are all on the same page regarding what minor and major versions are and their naming: 4.1 would be a minor version (improvements and features that don't break compatibility) and 5.0 would be a major version (compatibility breakages) - 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
Re: [DISCUSS] Releases after 4.0
> > My preference is for a simple annual major release cadence, with minors as > necessary. > I do not think that I fully understand your proposal. How do you define a major and a minor release? My understanding of a major release was a version that broke some of the compatibilities. By consequence, once a breaking change has been introduced it will not be possible to release a minor and we will have to wait for a major release. In a similar way if no breaking change has been introduced, does it make sense to release a major? On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith wrote: > Perhaps we could also consider quarterly "develop" releases, so that we > have pressure to maintain a shippable trunk? This provides some opportunity > for more releases without incurring the project maintenance costs or user > coordination costs. Something like a feature-incomplete mid-cycle RC, that > a user wanting shiny features can grab, providing feedback throughout the > development cycle. > > On 26/01/2021, 14:11, "Benedict Elliott Smith" > wrote: > > My preference is for a simple annual major release cadence, with > minors as necessary. This is simple for the user community and developer > community: support = x versions = x years. > > I'd like to pair this with stricter merge criteria, so that we > maintain a ~shippable trunk, and we cut a release at ~the same time every > year, whatever features are merged. We might have to get happy with > reverting commits that break things. > > I think faster cadences impose too much burden on the developer > community for maintenance and the user community for both upgrades and > making sense of what's going on. I think slower cadences collapse, as the > release window begins to collect too many hopes and dreams. > > My hope is that we get to a point where snapshots of trunk are safe to > run, and that major contributors are ahead of the release window for > internal consumption, rather than behind - this might also alleviate > pressure for hitting release windows with features. > > > > > On 26/01/2021, 13:56, "Benjamin Lerer" > wrote: > > Hi everybody > > It seems that there is a need to discuss how we will deal with > releases > after 4.0 > We are now relatively close from the 4.0 RC release so it make > sense to me > to start discussing that subject especially as it has some impact > on some > things like dropping support for python 2 > > The main questions are in my opinion: > 1) What release cadence do we want to use for major/minor versions? > 2) How do we plan to ensure the quality of the releases? > > It might make sense to try a release cadence and see how it works > out in > practice revisiting our decision if we feel the need for it. > > One important thing to discuss with the cadence is the amount of > time we > want to support the releases. 2.2 has been supported for more than > 5 years, > we might not be able to support releases for a similar time frame > if we > release a version every 6 months for example. > To be sure that we are all on the same page regarding what minor > and major > versions are and their naming: 4.1 would be a minor version > (improvements > and features that don't break compatibility) and 5.0 would be a > major > version (compatibility breakages) > > > > - > 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 > >
Re: [DISCUSS] Releases after 4.0
I understood us to have agreed to drop semver, because our major/minor history has been a meaningless distinction, and instead to go major/patch (or major/minor - with minor for patches), depending how you want to slice it. But there have been a lot of discussions over the past year or so, so I may be misremembering. On 27/01/2021, 13:25, "Benjamin Lerer" wrote: > > My preference is for a simple annual major release cadence, with minors as > necessary. > I do not think that I fully understand your proposal. How do you define a major and a minor release? My understanding of a major release was a version that broke some of the compatibilities. By consequence, once a breaking change has been introduced it will not be possible to release a minor and we will have to wait for a major release. In a similar way if no breaking change has been introduced, does it make sense to release a major? On Wed, Jan 27, 2021 at 11:21 AM Benedict Elliott Smith wrote: > Perhaps we could also consider quarterly "develop" releases, so that we > have pressure to maintain a shippable trunk? This provides some opportunity > for more releases without incurring the project maintenance costs or user > coordination costs. Something like a feature-incomplete mid-cycle RC, that > a user wanting shiny features can grab, providing feedback throughout the > development cycle. > > On 26/01/2021, 14:11, "Benedict Elliott Smith" > wrote: > > My preference is for a simple annual major release cadence, with > minors as necessary. This is simple for the user community and developer > community: support = x versions = x years. > > I'd like to pair this with stricter merge criteria, so that we > maintain a ~shippable trunk, and we cut a release at ~the same time every > year, whatever features are merged. We might have to get happy with > reverting commits that break things. > > I think faster cadences impose too much burden on the developer > community for maintenance and the user community for both upgrades and > making sense of what's going on. I think slower cadences collapse, as the > release window begins to collect too many hopes and dreams. > > My hope is that we get to a point where snapshots of trunk are safe to > run, and that major contributors are ahead of the release window for > internal consumption, rather than behind - this might also alleviate > pressure for hitting release windows with features. > > > > > On 26/01/2021, 13:56, "Benjamin Lerer" > wrote: > > Hi everybody > > It seems that there is a need to discuss how we will deal with > releases > after 4.0 > We are now relatively close from the 4.0 RC release so it make > sense to me > to start discussing that subject especially as it has some impact > on some > things like dropping support for python 2 > > The main questions are in my opinion: > 1) What release cadence do we want to use for major/minor versions? > 2) How do we plan to ensure the quality of the releases? > > It might make sense to try a release cadence and see how it works > out in > practice revisiting our decision if we feel the need for it. > > One important thing to discuss with the cadence is the amount of > time we > want to support the releases. 2.2 has been supported for more than > 5 years, > we might not be able to support releases for a similar time frame > if we > release a version every 6 months for example. > To be sure that we are all on the same page regarding what minor > and major > versions are and their naming: 4.1 would be a minor version > (improvements > and features that don't break compatibility) and 5.0 would be a > major > version (compatibility breakages) > > > > - > 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
Re: [DISCUSS] When to stop supporting Python 2
> > Does anybody know what are the practicalities/hurdles > that users can face when upgrading and what is the expected cost of keeping > support for 2.7 until the next major? > Given that the code supports both, the only barrier to the user is "does my distro have python3 (most likely), or would I have to install it?". The cost of keeping support is a small amount of drag as we consider fixing bugs and maintaining compatibility. It's not huge, but I don't see a lot of reasons to incur it. I want to emphasize here: to my way of thinking, "dropping support" at this juncture is just a matter of documenting it, and maybe introducing a warning. We don't need to *remove* support for python2. It will continue to work as-is. This would just guide us in deciding whether to work on flaws that are python2-specific, and whether new things are developed with backwards compatibility as a forcing concern. I'll have to catch up on the other ticket and see what bearing it has on this discussion. On Tue, Jan 26, 2021 at 1:46 AM Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> wrote: > +1 (nb) for dropping support for python2; I agree 4.0 major release is a > good time to do this, given python2 is already EOL. > > On Mon, Jan 25, 2021 at 2:00 PM Yifan Cai wrote: > > > +1 nb. > > We probably also want to set a milestone to get rid of the python2 > > compatible code completely, if we are going in the direction that drops > > python2 support in 4.0 and retains the python2 compatible code. In 4.x or > > 5.0? > > > > On Mon, Jan 25, 2021 at 9:24 AM Ekaterina Dimitrova < > e.dimitr...@gmail.com > > > > > wrote: > > > > > I support the idea, we are not removing python2-compatible code > > > +1 > > > > > > On Fri, 22 Jan 2021 at 15:14, Adam Holmberg < > adam.holmb...@datastax.com> > > > wrote: > > > > > > > As you may recall, CASSANDRA-10190 [1] introduced Python 3 support > for > > > > cqlsh. This change will be landing in 4.0. In the course of > development > > > and > > > > discussion spanning years, it was decided to retain support for > Python > > 2. > > > > In the meantime, Python 2 sunsetted (a year ago [2]). I hadn't seen a > > > > discussion about whether we intend to carry on support for Python 2, > so > > > I'm > > > > raising one here. > > > > > > > > 4.0 is a major release and we have an opportunity to drop support at > > this > > > > milestone. It has been mentioned that it will not be acceptable to do > > in > > > a > > > > minor or patch release, so if it's not done for 4.0, we will need to > > wait > > > > for the next major. I do understand that many in the project would > like > > > > majors on a more frequent interval post-4.0, but at this time we > don't > > > know > > > > when that will be. > > > > > > > > I advocate for dropping support ASAP. I expect that users should not > be > > > > inconvenienced by this -- I am not aware of a major distro that has > not > > > had > > > > python3 for years. Dropping python2 support does not mean that we > would > > > do > > > > work to rip out python2-compatible code, just that we wouldn't > > advertise > > > > support and any package requirements would be adjusted. We benefit by > > > > removing the need to test multiple runtimes, and we wouldn't be > > concerned > > > > with fixing python2-specific issues that may arise on the EOL runtime > > > [3]. > > > > > > > > I look forward to the discussion. > > > > > > > > -- > > > > Adam Holmberg > > > > e. adam.holmb...@datastax.com > > > > w. www.datastax.com > > > > > > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-10190 > > > > [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.python.org_doc_sunset-2Dpython-2D2_&d=DwIBaQ&c=adz96Xi0w1RHqtPMowiL2g&r=GgOKQUoTLCKbKh1M_uCZ-t7CW3HHZHE_I4OFzjDOiIs&m=PHNtl_WeGlGcuZQ1iwiajdr1eBZpuu1uxx8Ty-LCtiw&s=dDf0vhcr06PYYRjqcO9iwAWvN109cwYQNF6k9odIMIs&e= > > > > [3] https://issues.apache.org/jira/browse/CASSANDRA-16400 > > > > > > > > > > -- Adam Holmberg e. adam.holmb...@datastax.com w. www.datastax.com
Re: [DISCUSS] When to stop supporting Python 2
On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg wrote: > I want to emphasize here: to my way of thinking, "dropping support" at this > juncture is just a matter of documenting it, and maybe introducing a > warning. We don't need to *remove* support for python2. It will continue to > work as-is. This would just guide us in deciding whether to work on flaws > that are python2-specific, and whether new things are developed with > backwards compatibility as a forcing concern. Actually, I think we have to go a little bit further, and at least as far as packaging is concerned, remove support for python2. Recently pip updated to 21.0 and removed python2 support, which broke any builds that built artifacts requiring pip. We now pin pip: https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8 to get around this, but highlights that we too need to move away from anything using python2. So while we would not modify code to *remove* python2 support, you would have to invoke python2 on the code in your own way, since the packages would depend on python3. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] When to stop supporting Python 2
Python 2 was EOLed over a year ago. I think it's fine to (1) require python 3 to run cqlsh and (2) remove code that supports python 2 whenever it's convenient. Angelo has the right idea that rather than trying to finesse a deprecation cycle into 4.0 at this late date, a better migration path can be provided by backporting python3 support to 3.11. On Wed, Jan 27, 2021 at 12:36 PM Brandon Williams wrote: > On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg > wrote: > > I want to emphasize here: to my way of thinking, "dropping support" at > this > > juncture is just a matter of documenting it, and maybe introducing a > > warning. We don't need to *remove* support for python2. It will continue > to > > work as-is. This would just guide us in deciding whether to work on flaws > > that are python2-specific, and whether new things are developed with > > backwards compatibility as a forcing concern. > > Actually, I think we have to go a little bit further, and at least as > far as packaging is concerned, remove support for python2. Recently > pip updated to 21.0 and removed python2 support, which broke any > builds that built artifacts requiring pip. We now pin pip: > > https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8 > to get around this, but highlights that we too need to move away from > anything using python2. So while we would not modify code to *remove* > python2 support, you would have to invoke python2 on the code in your > own way, since the packages would depend on python3. > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
Sstableloader options on cassandra 3.11.9
Hi Cassandra Dev team, I was using Cassandra's bulk loading tool on a simple auth based setup. I found out that we need to pass *"-u and -pw" *parameters on Auth enabled Casandra setup. If I use the command using these parameters then if someone (any user with login access to Cassandra host machine) does *"ps -ef | grep -v grep | grep -E 'sstableloader'" *on Cassandra host machine other then Cassandra admin, then that user can see creds of the Cassandra user in plain text. I saw a similar issue while using the cqlsh and nodetool utility but there I found *"--cqlshrc and -pwf" *options where we can pass ACL based file and creds are not directly visible in ps command. *I am not able to find any such option with the Sstableloader utility. Can you suggest to me anyway by which I can pass Cassandra creds and those are not visible over the ps command? I am looking for a solution on Cassandra 3.11.9 or 3.x in general.* Regards Radha Wadhera
Cassandra 4.0 Status 2021-01-27
Greetings. Here’s a quick look at Cassandra 4.0 release status for the week. Eight days since the last report. Jira board with 4.0 scope: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661 High level numbers by release phase: Beta: 15 (-7); 10 in-flight; A good number of tickets were closed in this interval, and there are not many left in this scope. So close! RC: 38 (+1); 22 in-flight; Lots of good work happening here Top-level metrics: Total tickets in 4.0: 1518 Remaining tickets represent 3.5% of total scope Created vs. resolved continued in a positive trend: https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12347782&periodName=daily&daysprevious=45&cumulative=true&versionLabels=major&selectedProjectId=12310865&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Acreatedvsresolved-report&atl_token=A5KQ-2QAV-T4JA-FDED_a3bea645259beee42ed00c68f87626d5972705c4_lin&Next=Next Where you can help: * We’re within line-of-sight to closing out beta scope. Any work people can do on remaining blockers will accelerate the project toward RC. There are a handful of bugs, and PRs in need of review or merge. * Each filter referenced below depends on accurate assignments in Jira. In addition to actively assigning something you’re working on, it would also be helpful to review and unassign (both Reviewer and Assignee) things that you have assigned but may not be able to work on in the release timeline. In addition it is helpful to move things you’re on to “In Progress” to avoid folks having to check in on assigned tickets in “TO DO”. Here’s a query to check your current open+assigned items: https://issues.apache.org/jira/issues/?filter=12348585&jql=project%20%3D%20cassandra%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta%2C%204.0-rc%2C%204.0-alpha1%2C%204.0-alpha2%2C%204.0-alpha3%2C%204.0-alpha4%2C%204.0-alpha5%2C%204.0-alpha6%2C%204.0-beta-1%2C%204.0-beta1%2C%204.0-beta2%2C%204.0-beta3%2C%204.0-beta4)%20AND%20(resolution%20%3D%20unresolved%20OR%20status%20!%3D%20resolved)%20and%20(assignee%20%3D%20currentUser()%20or%20reviewer%20%3D%20currentUser()%20or%20reviewers%20%3D%20currentUser())%20 *Needs Reviewer: Single RC issue awaiting review without reviewers: https://issues.apache.org/jira/browse/CASSANDRA-16245 https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1659 *No assignee: 2 Beta and 5 RC issues Please take a look and see if it’s within your capacity to take any of these on: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1658 *Tickets stalled for a week: 3 beta, 23 GA https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661&quickFilter=1694 Please let us know on the thread if I have missed anything that needs attention. I encourage anyone to respond to these reports calling attention to any localized things that could use it. As always thanks to everyone for the continued hard work on the project. -- Adam Holmberg e. adam.holmb...@datastax.com w. www.datastax.com
