+1 for SystemML 1.0 as the next release. On Sat, Mar 4, 2017 at 10:23 AM, Deron Eriksson <deroneriks...@gmail.com> wrote:
> 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 over 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. > > How about just make SystemML Next and change the release name when we do the release ? > 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/ > -- Luciano Resende http://twitter.com/lresende1975 http://lresende.blogspot.com/
