I am not in disagreement with Matthias' point regarding removing code which no longer need to be supported and need additional effort to do maintenance.At the same time we need to avoid burden on users. Burden on users should be avoided at possible extent.
We have recently released SystemML 0.12 in end of Nov (Spark 1.x based) and SystemML 0.13 end of last week (Spark 2.x based).It will be harder for SystemML 0.13 (and more harder for SystemML 0.12) to move to SystemML 1.0 immediately due to code and interface change. To minimize impact to SystemML 0.12 and/or SystemML 0.13 users we have to back port code to these releases. We may need to decide how much back port needed on each of these releases. Once we break backward compatibility, maintenance will be even much harder (one or both releases) than to do maintain current code which to be removed. >From users convenience I prefer to go with one or two additional releases >without breaking backward compatibility. Note: If we go with code freeze by April 20, and breaking backward compatibility, I foresee this release will drag till end of May if not more. Lets keep release cycle for 2 months. ------------------------------------------------------- Arvind Surve | Spark Technology Center | http://www.spark.tc/ From: Deron Eriksson <deroneriks...@gmail.com> To: dev@systemml.incubator.apache.org Sent: Saturday, March 4, 2017 10:23 AM Subject: Re: Release cadence Personally I would like the next release to be 1.0. We have been an incubator project since November 2015 and I believe that after 1,000 commits since then that the project is about ready for a 1.0 release. I agree with Matthias that we need to make a decision regarding this topic. For new issues and fixed issues in JIRA, we need to be able to assign the correct version, or else someone potentially needs to go through and fix the version numbers, as Glenn has been doing. Additionally, it would be nice to do some of the 1.0 code updates (such as removing the old MLContext) now rather than waiting additional months. Also I would like to be able to correctly identify our next version in the online documentation. Deron On Sat, Mar 4, 2017 at 12:47 AM, Matthias Boehm <mboe...@googlemail.com> wrote: > thanks Arvind for bringing some structure to the release process. I think a > fixed cadence of 2 months is useful as it makes upcoming releases more > predictable for devs and users. > > However, we're discussing a major 1.0 release for a while now. I think it > would be useful to come to an agreement if we go for 1.0 in April or not. > There are some pending changes such as removing the old MLContext, removing > the file-based transform, isolating the matrix block library, and some > language changes that should only be addresses in a major release as they > break backwards compatibility. Right now, we can't touch these changes > without knowing the target release. > > Personally, I don't see a good reason why we should wait. Postponing this > major release just creates unnecessary overhead in maintaining these old > components that will be removed eventually. Since we cut RC for 0.13 on Feb > 20, I think having an RC around April 20 would be a good target for this > 1.0 release. > > > Regards, > Matthias > > > On Fri, Mar 3, 2017 at 5:44 PM, Arvind Surve <ac...@yahoo.com.invalid> > wrote: > > > Based on last couple of release cycles, we will continue with 2 months > > release cycles.We will do first RC build by end of first week of second > > month. > > We will plan on releasing next release by end of April 2017.We will have > > RC build on ~April 6th. -Arvind > > Arvind Surve | Spark Technology Center | http://www.spark.tc/ > > > > From: Acs S <ac...@yahoo.com.INVALID> > > To: "dev@systemml.incubator.apache.org" <dev@systemml.incubator. > > apache.org> > > Sent: Monday, January 9, 2017 11:41 AM > > Subject: Re: Release cadence > > > > We need to release SystemML on more frequent basis to get community > > engaged. It will provide us more feedback on functionality we add.While > > releasing SystemML on monthly basis is challenge due to longer phase of > > validation process we need to find a way to be quicker. > > I can propose options to get closer to monthly release if acceptable. > > Make every two releases available on monthly basis and third on two > months > > basis. This cycle will continue. > > 1. Do minimal testing on two releases (minor releases) and release them > on > > monthly basis. Performance testing is one of the major time consuming > > activity especially for larger data size. We can limit testing only upto > > 80GB. We can do code freeze (other than fixes) at the end of third week > and > > do verification on last week. If we find any issues we can still release > > the code with limitation documented unless issue breaks major > > functionality.2. Do comprehensive testing on third release. This will > > include performance testing for all data size and every other testing we > > do. We can do code freeze (other than fixes) at the end of third week and > > start verification of code. All issues found will be addressed. Exception > > will be considered. > > > > Meantime we need to start automating testing pieces. > > > > Arvind SurveSpark Technology Centerhttp://www.spark.tc/ > > > > From: Berthold Reinwald <reinw...@us.ibm.com> > > To: dev@systemml.incubator.apache.org > > Sent: Saturday, January 7, 2017 1:35 AM > > Subject: Re: Release cadence > > > > I think that a 2 month cycle would be a good compromise for major/minor > > releases. Fixpack release could be at a 1 month cycle. > > > > > > Regards, > > Berthold Reinwald > > IBM Almaden Research Center > > office: (408) 927 2208; T/L: 457 2208 > > e-mail: reinw...@us.ibm.com > > > > > > > > From: Deron Eriksson <deroneriks...@gmail.com> > > To: dev@systemml.incubator.apache.org > > Date: 01/05/2017 02:14 PM > > Subject: Re: Release cadence > > > > > > > > +1 for trying out a 1 month release cycle. > > > > However, I highly agree with Matthias that there is a lot of overhead > with > > releases, so it would be good if we can work to streamline/automate the > > process as much as possible. Also, it would be good to distribute the > > tasks > > around as much as possible. This can result in cross-training and help > > avoid overburdening the same contributors each month. > > > > If the overhead slows us down too much, then we can go to a slower > release > > cycle. > > > > Deron > > > > > > > > > > On Thu, Jan 5, 2017 at 1:50 PM, <dusenberr...@gmail.com> wrote: > > > > > +1 for adopting a 1 month release cycle. > > > > > > -- > > > > > > Mike Dusenberry > > > GitHub: github.com/dusenberrymw > > > LinkedIn: linkedin.com/in/mikedusenberry > > > > > > Sent from my iPhone. > > > > > > > > > > On Jan 5, 2017, at 1:35 PM, Luciano Resende <luckbr1...@gmail.com> > > > wrote: > > > > > > > > On Thu, Jan 5, 2017 at 6:05 AM, Matthias Boehm > > <mboe...@googlemail.com> > > > > wrote: > > > > > > > >> In general, I like the idea of aiming for consistent release cycles. > > > >> However, every month is just too much, at least for me. There is a > > > >> considerable overhead associated with each release for end-to-end > > > >> performance tests, tests on different environments, code freeze for > > new > > > >> features, etc. Hence, a too short release cycle would not be "agile" > > but > > > >> would actually slow us down. From my perspective, a realistic > release > > > >> cadence would be 2-3 months, maybe a bit more for major releases. > > > >> > > > >> > > > > 2-3 months of release cadence for an open source is probably a long > > > > stretch, particular for a project that does not have very large set > of > > > 3rd > > > > party dependencies. > > > > > > > > As for some of the overhead issues you mentioned, they are probably > > easy > > > to > > > > workaround: > > > > > > > > - code-freeze timeframe can be resolved with branches > > > > - end-to-end performance regressions can be avoided by better code > > > review, > > > > and if you were willing to go with 2-3 months without performing > these > > > > tests, we could perform them only for major releases, and proactively > > > > quickly build a minor release with the patch when a user report any > > > > performance regression. > > > > > > > > > > > > Anyway, I would really like to see SystemML more agile with regards > to > > > its > > > > release process because, as I mentioned before, the release early, > > > release > > > > often mantra is good to increase community interest, generate more > > > traffic > > > > to the list as developers discuss the roadmap and release blockers, > > and > > > > also enable users to provide feedback sooner on the areas we are > > > developing. > > > > > > > > > > > > > > > > -- > > > > Luciano Resende > > > > http://twitter.com/lresende1975 > > > > http://lresende.blogspot.com/ > > > > > > > > > > > -- > > Deron Eriksson > > Spark Technology Center > > http://www.spark.tc/ > > > > > > > > > > > > > > > > > -- Deron Eriksson Spark Technology Center http://www.spark.tc/
