On Sun, Sep 27, 2015 at 3:06 AM, Yakov Zhdanov <yzhda...@apache.org> wrote:
> Cos, believe me there will be efforts. How about maven poms and automated > procedures? This will need to be fixed and retested. I want to avoid it > unless it's absolutely needed. > I agree with Yakov. We have not had a single issue with these version names. Why fix that's not broken? > > Thanks! > > Yakov > On Sep 27, 2015 12:24, "Konstantin Boudnik" <c...@apache.org> wrote: > > > On Sun, Sep 27, 2015 at 12:11AM, Yakov Zhdanov wrote: > > > I would leave it as is for now. Just to avoid any extra efforts. > Another > > > > There's no effort in it, really - I can rename the versions in the next > 15 > > seconds. Or better yet - let's leave 1.4* as it is, and start normalized > > version naming in JIRA from 1.5 and on. It won't affect anything, and all > > remaining tickets from ignite-1.4 - if any - will be automatically moved > to > > 1.5 once you close the current release in JIRA. > > > > > point is - what if we decide to release products like accelerator for > > > hadoop or data fabric for .net separately at some point? We will need > to > > > somehow distinguish. > > > > Using versions to distinguish between release composition is pretty bad > > idea. > > I don't even remember how many times people were burned by it. If we need > > to > > release a separate fabric for .net you'd do > > ignite-fabric-net-1.5-src.tgz > > ignite-fabric-1.5-src.tgz > > > > It still will be 1.5 but you'd have two different source artifacts. If > you > > decide not to release fabric for anything else but .net in 1.5 - then you > > just > > won't have the second source file around. > > > > Cos > > > > > --Yakov > > > > > > 2015-09-26 23:23 GMT+03:00 Raul Kripalani <r...@evosent.com>: > > > > > > > Agree. And we should also normalise tag names and branch names in Git > > if > > > > they aren't (cannot check now). > > > > > > > > What do you think about creating a new branch per release like it's > > being > > > > done now? > > > > > > > > In other projects (OSS and non-OSS) we tend to create and leave open > a > > > > maintenance branch once per minor version (e.g. ignite-1.4) rather > can > > > > creating and deleting branches for every particular version. We do > this > > > > once the first release in that maintenance line is cut from master. > > > > On 26 Sep 2015 17:16, "Konstantin Boudnik" <c...@apache.org> wrote: > > > > > > > > > On a somewhat similar note: I just noticed that our versions have > > prefix > > > > > "ignite-". Do we really need it? It is sorta obvious that these are > > > > > Ignite's > > > > > versions, not httpd's :) It seems a bit confusing that JIRA > versions > > > > still > > > > > aren't the same as the release ones. > > > > > > > > > > Shall we move to just numerical versions like 1.5 and so on and do > it > > > > > starting from 1.5? > > > > > > > > > > Cos > > > > > > > > > > ----- Forwarded message from Dmitriy Setrakyan < > > dsetrak...@apache.org> > > > > > ----- > > > > > > > > > > Date: Sat, 26 Sep 2015 10:50:08 -0500 > > > > > From: Dmitriy Setrakyan <dsetrak...@apache.org> > > > > > To: dev@ignite.apache.org > > > > > Subject: Re: Need Project Admin rights on JIRA > > > > > > > > > > Done. > > > > > > > > > > On Sat, Sep 26, 2015 at 5:27 AM, Raul Kripalani <ra...@apache.org> > > > > wrote: > > > > > > > > > > > Hi guys, > > > > > > > > > > > > I need project admin rights for Ignite in JIRA so I can add a new > > > > release > > > > > > ignite-1.4.1. > > > > > > > > > > > > For future releases, it would be great if the release manager > adds > > the > > > > > next > > > > > > micro [and minor [and major]] versions in JIRA when cutting the > > first > > > > RC. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > *Raúl Kripalani* > > > > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big > > Data > > > > and > > > > > > Messaging Engineer > > > > > > http://about.me/raulkripalani | > > > > http://www.linkedin.com/in/raulkripalani > > > > > > http://blog.raulkr.net | twitter: @raulvk > > > > > > > > > > > > > > > > ----- End forwarded message ----- > > > > > > > > > > > >
