You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@livy.apache.org by Bikas Saha <bi...@apache.org> on 2017/09/06 20:30:29 UTC
[DISCUSS] Release Cadence
Hi,
We just did our first release and hopefully have ironed out the release mechanics and also provided users a transition point to move over their dependencies to ASF.
I think now would be a good time to figure out our release mechanics.
IMO time based release mechanics have worked out well for projects like Apache Spark. Regular releases allow for timely updates with bug fixes for increased stability. Also, they reduce unnecessary angst around features making into release because there is always the next timely release to latch on to in case the current release is missed.
Are there other things to consider? E.g. making a concurrent release (even if its ad-hoc) to match Apache Spark releases because there is a strong dependency on the project. That would depend on whether we depend/integrate with new features in that Spark release.
Thanks
Bikas
Re: [DISCUSS] Release Cadence
Posted by Alex Bozarth <aj...@us.ibm.com>.
Sounds good to me, I'm working on fleshing out documentation and adding
javadocs, but that's more of an improvement than a feature.
Alex Bozarth
Software Engineer
Spark Technology Center
E-mail: ajbozart@us.ibm.com
GitHub: github.com/ajbozarth
505 Howard Street
San Francisco, CA 94105
United States
From: Bikas Saha <bi...@outlook.com>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/07/2017 04:23 PM
Subject: Re: [DISCUSS] Release Cadence
Hi,
If 3 months is agreeable then November would be on the plate. I think the
shared context across languages is a super useful user feature that could
be released. Any other features that could go in for that time frame?
Bikas
________________________________
From: Alex Bozarth <aj...@us.ibm.com>
Sent: Wednesday, September 6, 2017 2:05 PM
To: dev@livy.incubator.apache.org
Subject: Re: [DISCUSS] Release Cadence
I'm ok with 3 months, and I agree about the December issue, would you
suggest a November release then or wait until January?
Alex Bozarth
Software Engineer
Spark Technology Center
________________________________
E-mail: ajbozart@us.ibm.com<ma...@us.ibm.com>
GitHub: github.com/ajbozarth<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajbozarth&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=K0WPyiqakFHs_xxQvu3rwaJYj-NBi7aMb01KHHV8s3c&s=8jI9_7qV9Dh7_-rQh_OjK-qcE4cIB7JPRDAwu-5PVSs&e=
>
505 Howard Street
San Francisco, CA 94105
United States
[Inactive hide details for Bikas Saha ---09/06/2017 02:01:26 PM---Hi, 4
months might be too long for a relatively new project li]Bikas Saha
---09/06/2017 02:01:26 PM---Hi, 4 months might be too long for a relatively
new project like Livy. And doing a release in Decemb
From: Bikas Saha <bi...@outlook.com>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 02:01 PM
Subject: Re: [DISCUSS] Release Cadence
________________________________
Hi,
4 months might be too long for a relatively new project like Livy. And
doing a release in December might not be easy with that being holiday
season in many places.
I was thinking of following Spark's history of 3 month releases initially.
That provides about 2 months of feature development work followed by 1
month of time to start a release, go through bug fixes and finish the
process. To be clear, that would be for major releases like 0.5, 0.6 etc.
If sufficient bug fixes accumulate much earlier than that then a minor bug
fix release could be done ahead of time, like you suggest. Specially if
these end up being security fixes.
Bikas
________________________________
From: Alex Bozarth <aj...@us.ibm.com>
Sent: Wednesday, September 6, 2017 1:54 PM
To: dev@livy.incubator.apache.org
Subject: Re: [DISCUSS] Release Cadence
I think we discussed this some in a previous chain and came to the general
consensus that a time based release cadence was best but didn't settle on
the cadence length. Personally I think every 4 months (thus our next
release around new years) would work well and give us flexibility to
release a bit early or late to match with a Spark release if necessary. I
would say every 6 months based on our previous release rate, but I think
that cadence is too long if we want the project to continue to gain
momentum. As for maintenance/patch releases I think we should release
whenever there's enough fixes to warrant it.
Alex Bozarth
Software Engineer
Spark Technology Center
________________________________
E-mail: ajbozart@us.ibm.com<ma...@us.ibm.com>
GitHub: github.com/ajbozarth<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajbozarth&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=E5PTfuFmbFjYDn2SKKQ0eTbeQ__nwGToXjZeG5BGQ-8&s=MKOBWohtx6XyGFWKBIof5c3fv-RfVu6MLo2QHN1H5u8&e=
>
505 Howard Street
San Francisco, CA 94105
United States
[Inactive hide details for Bikas Saha ---09/06/2017 01:42:11 PM---Hi, We
just did our first release and hopefully have ironed ou]Bikas Saha
---09/06/2017 01:42:11 PM---Hi, We just did our first release and hopefully
have ironed out the release mechanics and also provi
From: Bikas Saha <bi...@apache.org>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 01:42 PM
Subject: [DISCUSS] Release Cadence
________________________________
Hi,
We just did our first release and hopefully have ironed out the release
mechanics and also provided users a transition point to move over their
dependencies to ASF.
I think now would be a good time to figure out our release mechanics.
IMO time based release mechanics have worked out well for projects like
Apache Spark. Regular releases allow for timely updates with bug fixes for
increased stability. Also, they reduce unnecessary angst around features
making into release because there is always the next timely release to
latch on to in case the current release is missed.
Are there other things to consider? E.g. making a concurrent release (even
if its ad-hoc) to match Apache Spark releases because there is a strong
dependency on the project. That would depend on whether we depend/integrate
with new features in that Spark release.
Thanks
Bikas
Re: [DISCUSS] Release Cadence
Posted by Bikas Saha <bi...@outlook.com>.
Hi,
If 3 months is agreeable then November would be on the plate. I think the shared context across languages is a super useful user feature that could be released. Any other features that could go in for that time frame?
Bikas
________________________________
From: Alex Bozarth <aj...@us.ibm.com>
Sent: Wednesday, September 6, 2017 2:05 PM
To: dev@livy.incubator.apache.org
Subject: Re: [DISCUSS] Release Cadence
I'm ok with 3 months, and I agree about the December issue, would you suggest a November release then or wait until January?
Alex Bozarth
Software Engineer
Spark Technology Center
________________________________
E-mail: ajbozart@us.ibm.com<ma...@us.ibm.com>
GitHub: github.com/ajbozarth<https://github.com/ajbozarth>
505 Howard Street
San Francisco, CA 94105
United States
[Inactive hide details for Bikas Saha ---09/06/2017 02:01:26 PM---Hi, 4 months might be too long for a relatively new project li]Bikas Saha ---09/06/2017 02:01:26 PM---Hi, 4 months might be too long for a relatively new project like Livy. And doing a release in Decemb
From: Bikas Saha <bi...@outlook.com>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 02:01 PM
Subject: Re: [DISCUSS] Release Cadence
________________________________
Hi,
4 months might be too long for a relatively new project like Livy. And doing a release in December might not be easy with that being holiday season in many places.
I was thinking of following Spark's history of 3 month releases initially. That provides about 2 months of feature development work followed by 1 month of time to start a release, go through bug fixes and finish the process. To be clear, that would be for major releases like 0.5, 0.6 etc.
If sufficient bug fixes accumulate much earlier than that then a minor bug fix release could be done ahead of time, like you suggest. Specially if these end up being security fixes.
Bikas
________________________________
From: Alex Bozarth <aj...@us.ibm.com>
Sent: Wednesday, September 6, 2017 1:54 PM
To: dev@livy.incubator.apache.org
Subject: Re: [DISCUSS] Release Cadence
I think we discussed this some in a previous chain and came to the general consensus that a time based release cadence was best but didn't settle on the cadence length. Personally I think every 4 months (thus our next release around new years) would work well and give us flexibility to release a bit early or late to match with a Spark release if necessary. I would say every 6 months based on our previous release rate, but I think that cadence is too long if we want the project to continue to gain momentum. As for maintenance/patch releases I think we should release whenever there's enough fixes to warrant it.
Alex Bozarth
Software Engineer
Spark Technology Center
________________________________
E-mail: ajbozart@us.ibm.com<ma...@us.ibm.com>
GitHub: github.com/ajbozarth<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajbozarth&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=E5PTfuFmbFjYDn2SKKQ0eTbeQ__nwGToXjZeG5BGQ-8&s=MKOBWohtx6XyGFWKBIof5c3fv-RfVu6MLo2QHN1H5u8&e= >
505 Howard Street
San Francisco, CA 94105
United States
[Inactive hide details for Bikas Saha ---09/06/2017 01:42:11 PM---Hi, We just did our first release and hopefully have ironed ou]Bikas Saha ---09/06/2017 01:42:11 PM---Hi, We just did our first release and hopefully have ironed out the release mechanics and also provi
From: Bikas Saha <bi...@apache.org>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 01:42 PM
Subject: [DISCUSS] Release Cadence
________________________________
Hi,
We just did our first release and hopefully have ironed out the release mechanics and also provided users a transition point to move over their dependencies to ASF.
I think now would be a good time to figure out our release mechanics.
IMO time based release mechanics have worked out well for projects like Apache Spark. Regular releases allow for timely updates with bug fixes for increased stability. Also, they reduce unnecessary angst around features making into release because there is always the next timely release to latch on to in case the current release is missed.
Are there other things to consider? E.g. making a concurrent release (even if its ad-hoc) to match Apache Spark releases because there is a strong dependency on the project. That would depend on whether we depend/integrate with new features in that Spark release.
Thanks
Bikas
Re: [DISCUSS] Release Cadence
Posted by Alex Bozarth <aj...@us.ibm.com>.
I'm ok with 3 months, and I agree about the December issue, would you
suggest a November release then or wait until January?
Alex Bozarth
Software Engineer
Spark Technology Center
E-mail: ajbozart@us.ibm.com
GitHub: github.com/ajbozarth
505 Howard Street
San Francisco, CA 94105
United States
From: Bikas Saha <bi...@outlook.com>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 02:01 PM
Subject: Re: [DISCUSS] Release Cadence
Hi,
4 months might be too long for a relatively new project like Livy. And
doing a release in December might not be easy with that being holiday
season in many places.
I was thinking of following Spark's history of 3 month releases initially.
That provides about 2 months of feature development work followed by 1
month of time to start a release, go through bug fixes and finish the
process. To be clear, that would be for major releases like 0.5, 0.6 etc.
If sufficient bug fixes accumulate much earlier than that then a minor bug
fix release could be done ahead of time, like you suggest. Specially if
these end up being security fixes.
Bikas
________________________________
From: Alex Bozarth <aj...@us.ibm.com>
Sent: Wednesday, September 6, 2017 1:54 PM
To: dev@livy.incubator.apache.org
Subject: Re: [DISCUSS] Release Cadence
I think we discussed this some in a previous chain and came to the general
consensus that a time based release cadence was best but didn't settle on
the cadence length. Personally I think every 4 months (thus our next
release around new years) would work well and give us flexibility to
release a bit early or late to match with a Spark release if necessary. I
would say every 6 months based on our previous release rate, but I think
that cadence is too long if we want the project to continue to gain
momentum. As for maintenance/patch releases I think we should release
whenever there's enough fixes to warrant it.
Alex Bozarth
Software Engineer
Spark Technology Center
________________________________
E-mail: ajbozart@us.ibm.com<ma...@us.ibm.com>
GitHub: github.com/ajbozarth<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ajbozarth&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=S1_S7Dymu4ZL6g7L21O78VQZ53vEnAyZ-cx37DPYDyo&m=E5PTfuFmbFjYDn2SKKQ0eTbeQ__nwGToXjZeG5BGQ-8&s=MKOBWohtx6XyGFWKBIof5c3fv-RfVu6MLo2QHN1H5u8&e=
>
505 Howard Street
San Francisco, CA 94105
United States
[Inactive hide details for Bikas Saha ---09/06/2017 01:42:11 PM---Hi, We
just did our first release and hopefully have ironed ou]Bikas Saha
---09/06/2017 01:42:11 PM---Hi, We just did our first release and hopefully
have ironed out the release mechanics and also provi
From: Bikas Saha <bi...@apache.org>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 01:42 PM
Subject: [DISCUSS] Release Cadence
________________________________
Hi,
We just did our first release and hopefully have ironed out the release
mechanics and also provided users a transition point to move over their
dependencies to ASF.
I think now would be a good time to figure out our release mechanics.
IMO time based release mechanics have worked out well for projects like
Apache Spark. Regular releases allow for timely updates with bug fixes for
increased stability. Also, they reduce unnecessary angst around features
making into release because there is always the next timely release to
latch on to in case the current release is missed.
Are there other things to consider? E.g. making a concurrent release (even
if its ad-hoc) to match Apache Spark releases because there is a strong
dependency on the project. That would depend on whether we depend/integrate
with new features in that Spark release.
Thanks
Bikas
Re: [DISCUSS] Release Cadence
Posted by Bikas Saha <bi...@outlook.com>.
Hi,
4 months might be too long for a relatively new project like Livy. And doing a release in December might not be easy with that being holiday season in many places.
I was thinking of following Spark's history of 3 month releases initially. That provides about 2 months of feature development work followed by 1 month of time to start a release, go through bug fixes and finish the process. To be clear, that would be for major releases like 0.5, 0.6 etc.
If sufficient bug fixes accumulate much earlier than that then a minor bug fix release could be done ahead of time, like you suggest. Specially if these end up being security fixes.
Bikas
________________________________
From: Alex Bozarth <aj...@us.ibm.com>
Sent: Wednesday, September 6, 2017 1:54 PM
To: dev@livy.incubator.apache.org
Subject: Re: [DISCUSS] Release Cadence
I think we discussed this some in a previous chain and came to the general consensus that a time based release cadence was best but didn't settle on the cadence length. Personally I think every 4 months (thus our next release around new years) would work well and give us flexibility to release a bit early or late to match with a Spark release if necessary. I would say every 6 months based on our previous release rate, but I think that cadence is too long if we want the project to continue to gain momentum. As for maintenance/patch releases I think we should release whenever there's enough fixes to warrant it.
Alex Bozarth
Software Engineer
Spark Technology Center
________________________________
E-mail: ajbozart@us.ibm.com<ma...@us.ibm.com>
GitHub: github.com/ajbozarth<https://github.com/ajbozarth>
505 Howard Street
San Francisco, CA 94105
United States
[Inactive hide details for Bikas Saha ---09/06/2017 01:42:11 PM---Hi, We just did our first release and hopefully have ironed ou]Bikas Saha ---09/06/2017 01:42:11 PM---Hi, We just did our first release and hopefully have ironed out the release mechanics and also provi
From: Bikas Saha <bi...@apache.org>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 01:42 PM
Subject: [DISCUSS] Release Cadence
________________________________
Hi,
We just did our first release and hopefully have ironed out the release mechanics and also provided users a transition point to move over their dependencies to ASF.
I think now would be a good time to figure out our release mechanics.
IMO time based release mechanics have worked out well for projects like Apache Spark. Regular releases allow for timely updates with bug fixes for increased stability. Also, they reduce unnecessary angst around features making into release because there is always the next timely release to latch on to in case the current release is missed.
Are there other things to consider? E.g. making a concurrent release (even if its ad-hoc) to match Apache Spark releases because there is a strong dependency on the project. That would depend on whether we depend/integrate with new features in that Spark release.
Thanks
Bikas
Re: [DISCUSS] Release Cadence
Posted by Alex Bozarth <aj...@us.ibm.com>.
I think we discussed this some in a previous chain and came to the general
consensus that a time based release cadence was best but didn't settle on
the cadence length. Personally I think every 4 months (thus our next
release around new years) would work well and give us flexibility to
release a bit early or late to match with a Spark release if necessary. I
would say every 6 months based on our previous release rate, but I think
that cadence is too long if we want the project to continue to gain
momentum. As for maintenance/patch releases I think we should release
whenever there's enough fixes to warrant it.
Alex Bozarth
Software Engineer
Spark Technology Center
E-mail: ajbozart@us.ibm.com
GitHub: github.com/ajbozarth
505 Howard Street
San Francisco, CA 94105
United States
From: Bikas Saha <bi...@apache.org>
To: "dev@livy.incubator.apache.org" <de...@livy.incubator.apache.org>
Date: 09/06/2017 01:42 PM
Subject: [DISCUSS] Release Cadence
Hi,
We just did our first release and hopefully have ironed out the release
mechanics and also provided users a transition point to move over their
dependencies to ASF.
I think now would be a good time to figure out our release mechanics.
IMO time based release mechanics have worked out well for projects like
Apache Spark. Regular releases allow for timely updates with bug fixes for
increased stability. Also, they reduce unnecessary angst around features
making into release because there is always the next timely release to
latch on to in case the current release is missed.
Are there other things to consider? E.g. making a concurrent release (even
if its ad-hoc) to match Apache Spark releases because there is a strong
dependency on the project. That would depend on whether we depend/integrate
with new features in that Spark release.
Thanks
Bikas