Yeah, tag names need to be fixed going forward - they look funny for sure.
Something like
release-x.y.z
would be more preferrable.
Cos
On Sun, Sep 27, 2015 at 03:59PM, Raul Kripalani wrote:
> On Sun, Sep 27, 2015 at 10:20 AM, Konstantin Boudnik <c...@apache.org> wrote:
>
> > On Sat, Sep 26, 2015 at 09:23PM, Raul Kripalani wrote:
> > > Agree. And we should also normalise tag names and branch names in Git if
> > > they aren't (cannot check now).
> >
> > Tag names aren't much of the concern IMO, but it won't hurt either. Version
> > numbers are more visible, and their mishandling might have dire
> > consequences.
> >
>
> Cos, correct me if I'm wrong, but what you're bringing up is a matter of
> superfluous information in the JIRA version numbers. To me, that's just
> aesthetics and not so important.
>
> The point I'm making is one of consistency. Currently we have:
>
> a) Inconsistent tag names:
>
> $] git tag -l
> ...
> 1.3.2
> 1.3.2-p2
> 1.3.3
> ...
> 1.4.1
> ...
> ignite-1.3.0-incubating-rc1
> ignite-1.3.0-incubating-rc2
> ignite-1.4.0-SNAPSHOT-rc1
> ...
> release-1.0.0-RC3
>
> We need consistent nomenclature. Of course, some tags are historical, some
> are leftovers from the incubation, but all of them are visible to our
> users... We ought to do housekeeping. I'd be up for the job, but since I'm
> relatively new here and don't have the project's history, someone else is
> more appropriate.
>
> b) Confusing branch names:
>
> ...
> ignite-1168
> ignite-1169
> ignite-1170
> ignite-1171
> ...
> ignite-1.4
> ignite-1.4.1
>
> All of our 230+ branches start with "ignite" in a linear fashion, no matter
> if they are feature branches (ignite-nnnn => ticket number) or a
> maintenance/release branch (ignite-x.y.z). The moment we have IGNITE-2nnn
> tickets + an Ignite 2.y.z release, it's gonna get evil.
>
> Hence I propose to categorise branches with prefixes "feature/",
> "release/", "stream/", etc. Actual prefixes up for discussion.
>
>
> >
> > > 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.
> >
> > We have this lengthy discussion a few months back
> >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Git-branches-and-development-process-tp889p945.html
> >
> > and it got settled.
> >
>
> Thanks for the reference. Branko's proposal is pretty much standard
> industry practice and it contains the point I'm making. However, the devil
> is in the details. He said:
>
> > When you're ready to begin stabilization for a release, create a
> > release branch (rel-1.2.x for example) from the master branch. Only
> > bug fixes happen on the release branch. When you're happy with the
> > stability of the release, just tag the release branch (e.g., 1.2.0)
> > and publish. *This now becomes the bugfix branch for the 1.2.x
> release. *
>
> Note the last sentence. This means creating a long-lived ignite-1.4.x
> branch for maintenance, where each release == a tag within it (well,
> technically of a fork because there'll be an additional commit changing POM
> versions to release versions).
>
> In contrast, what's happening now is that the ignite-1.4 branch is
> abandoned and ignite-1.4.1 is created out of it, carrying over the history
> from ignite-1.4. So maintenance branches (or bugfix, to paraphrase him) are
> not long-lived but ephemeral (à la "release branch"). That wasn't what the
> community settled on, and that's the point I'm trying to make.
>
> In other words: we have no ignite-1.4.x branch, rather:
> ignite-1.4.0 (dead)
> ignite-1.4.1
> ...
>
> P.S.: I sympathise if you feel this email is long, but there's no other way
> to get my point across ;-)
>
>
> > Cos
> >
> > > 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 -----
> > > >
> >
