You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Matthieu Riou <ma...@offthelip.org> on 2009/02/06 23:35:50 UTC
No beta or RC?
Hi guys,
The logic in release strips out any letter that comes after the last ('.' +
digit) in a project release number. So something like 1.2-beta will actually
be released as 1.2. Sounds to me like a bug but I just wanted to check
before that it wasn't by design, an adoption of the 'no letter in releases'
RubyGem doctrine.
Given that the actual goal is only to strip an ending "-SNAPSHOT", the fix
is pretty straightforward.
Cheers,
Matthieu
Re: No beta or RC?
Posted by Alexis Midon <al...@gmail.com>.
Be aware that the version is incremented by the release
task<http://github.com/vic/buildr/blob/e35bc0fe8a0309d4cfdfb980af61cdb6f1a9990c/lib/buildr/core/build.rb#L292>
.
Alexis
On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com> wrote:
> The Maven conventions don't restrict the version to only numbers, so yeah,
> buildr should only strip a "-SNAPSHOT" suffix.
>
> alex
>
>
> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <matthieu@offthelip.org
> >wrote:
>
> > Hi guys,
> >
> > The logic in release strips out any letter that comes after the last ('.'
> +
> > digit) in a project release number. So something like 1.2-beta will
> > actually
> > be released as 1.2. Sounds to me like a bug but I just wanted to check
> > before that it wasn't by design, an adoption of the 'no letter in
> releases'
> > RubyGem doctrine.
> >
> > Given that the actual goal is only to strip an ending "-SNAPSHOT", the
> fix
> > is pretty straightforward.
> >
> > Cheers,
> > Matthieu
> >
>
Re: No beta or RC?
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Feb 9, 2009 at 4:53 PM, Alex Boisvert <bo...@intalio.com> wrote:
> Oh, right, you mean the "qualifier".
>
> Here's what Better Builds with
> Maven<http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
> >says,
>
> With regard to ordering, the elements are considered in sequence to
> determine which is newer - first by major version, second - if the major
> versions were equal - by minor version, third by bug fix version, fourth by
> qualifier (using string comparison), and finally, by build number. A
> version
> that contains a qualifier is older than a version without a qualifier; for
> example, 1.2-beta is older than version 1.2. A version that also contains a
> build number is considered newer than a version without a build number;
> for example, 1.2-beta-1 is newer than 1.2-beta.
Sonatype's site is down, so I used a cached copy from Feb 14 [1], but here's
what it has to say:
"The qualifier exists to capture milestone builds: alpha and beta
releases, and the qualifier is separated from the major, minor, and
incremental versions by a hyphen."
I'm not sure how Better Builds misinterpreted this and decided that versions
with qualifiers are older than versions without qualifiers, but by design
1.2 comes after 1.2-beta.
Also:
"Maven is supposed to treat the number after the qualifier as a build
number. In other words, the qualifier should be "alpha", and the build
number should be 2. Even though Maven has been designed to separate the
build number from the qualifier, this parsing is currently broken. "
So in theory beta-1 is newer than beta because it contains a build number,
but in practice beta-1 is newer because it's a longer string. Except
SNAPSHOT, which is a special qualifier that references the most recent
qualifier that happens to look like this:
"Maven would expand this version to ???1.0-20080207-230803-1??? if you
were to deploy a release at 11:08 PM on February 7th, 2008UTC."
So all this, the too many rules, the books that don't agree with each other,
a broken implementation, just reaffirms my point that the Maven versioning
scheme was an exercise in unnecessary complexity and the best way to deal
with it is to ignore it.
Compare to OSGI. A version number with no qualifier refers to the most
recent version with any qualifier value, which is just what you would expect
when you say "1.2.1", i.e. find me the most recent "1.2.1" you've got.
Qualifiers are ordered lexicographically, with no special rules that depend
on their value, no attempt to deconstruct them, so the algorithm is dead
simple and fool-proof and you can expect all the implementations to support
it. You just have to decide what to put in the qualifier. You can, say, have
R<timestamp> for releases, M<name-number> for milestones, and D<timestamp>
for development builds because R > M > B and conveniently alpha < beta < rc.
D would be the equivalent of a snapshot, and you'll just point to a
repository full of D artifacts during development, and stop pointing to it
when making milestones and final releases.
Assaf
[1]
http://209.85.173.132/search?q=cache:4B1vfCjEM3YJ:www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html+maven+version+qualifier+numeric&hl=en&ct=clnk&cd=5&gl=us&client=safari
>
> But my point still stands, Buildr should drop the SNAPSHOT qualifier (and
> only SNAPSHOT) during a release.
>
> alex
>
>
>
> On Mon, Feb 9, 2009 at 4:36 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
> >
> >
> > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > Ugh? If beta is not a release but a pre-release, how do you
> pre-release
> >> a
> >> beta?
> >>
> >
> > Then maybe it's called something else, either way the fourth part is
> > constrained.
> >
> >
> >
> >
> >
> >>
> >>
> >> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> >>
> >> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
> >>> wrote:
> >>>
> >>> The Maven conventions don't restrict the version to only numbers, so
> >>>>
> >>> yeah,
> >>>
> >>>> buildr should only strip a "-SNAPSHOT" suffix.
> >>>>
> >>>
> >>>
> >>> Actually it does: releases must end with numbers, pre-releases (rc,
> beta,
> >>> etc) with alphanumerics, and therefore 0 by virtue of being a release
> is
> >>> higher than beta2. OSGi uses alphanumerics on the fourth part, other
> >>> package managers have their own conventions. Buildr doesn't follow
> >>> anything
> >>> more complicated than numerical.
> >>>
> >>> Assaf
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> alex
> >>>>
> >>>>
> >>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <matthieu@offthelip.org
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>
> >>>> Hi guys,
> >>>>>
> >>>>> The logic in release strips out any letter that comes after the last
> >>>>>
> >>>> ('.'
> >>>
> >>>> +
> >>>>
> >>>>> digit) in a project release number. So something like 1.2-beta will
> >>>>> actually
> >>>>> be released as 1.2. Sounds to me like a bug but I just wanted to
> check
> >>>>> before that it wasn't by design, an adoption of the 'no letter in
> >>>>>
> >>>> releases'
> >>>>
> >>>>> RubyGem doctrine.
> >>>>>
> >>>>> Given that the actual goal is only to strip an ending "-SNAPSHOT",
> the
> >>>>>
> >>>> fix
> >>>>
> >>>>> is pretty straightforward.
> >>>>>
> >>>>> Cheers,
> >>>>> Matthieu
> >>>>>
> >>>>>
> >>>>
> >>>
>
Re: No beta or RC?
Posted by Matthieu Riou <ma...@gmail.com>.
On Fri, Feb 20, 2009 at 1:14 AM, Assaf Arkin <ar...@intalio.com> wrote:
> There are actually three, helps to separate them, issues we have to deal
> with:
>
> 1. Qualifiers, so you can make a 1.2-beta1 release and follow it with a
> 1.2-beta2 release. There are two approaches to qualifiers, I'll get to
> those
> in a moment. Right now there's no support in Buildr for either one.
>
> 2. Snapshots make it easy to share artifacts you're working on right now
> without overhead of making a release. A snapshot is just the most recent
> set
> of artifacts you created.
>
I'm not sure that's a problem worth solving. If I just give you a snapshot
of a library I'm working on, I can always rename the file to whatever I mean
to convey when I share it. My point is: it's not distribution so it's not
release.
>
> 3. Working in different branches, under the same version, and being able
> to
> tell these artifacts apart.
>
> The release task doesn't support 1, 2 or 3 and there was some confusing
> attempting to solve all three at the same time. So the most important point
> was realizing that we're looking at three things and splitting them.
>
>
> Qualifiers. Developers just don't like to see version numbers go to waste,
> it offends them to no end when you jump from 1.2.6 straight to 1.3.2. That
> means you can't use 1.3.0 for a beta release and 1.3.1 for release
> candidate, because most people would only get to see 1.3.2 as the first
> 1.3.x leading to horrible, possibly catastrophic results. People have been
> killed for lesser crimes.
>
> So qualifiers come to the rescue, and here we have two approaches. There's
> "qualifier is just a string, and if you don't specify one, you're referring
> to the most recent", which is the approach I've seen used most often. And
> there's the Maven approach, which is just nuts. We don't support either
> one,
> and we know Maven with all its rules is incompatible with OSGi and it's
> single, sane, rule, and I for one would favor going the OSGi route which
> means:
>
> Qualifier is a string, sorted lexicographically.
>
>
> Snapshots. The deal with snapshot is very simple. In development mode you
> want to reference the most recent version of something, which could change
> any minute, you might be building it from a different project, or someone
> else is building it for you. You might need to get very particular, and
> each
> snapshot release has a specific version number, but most of the time you
> don't care and just want to work with the latest.
>
> Using the -SNAPSHOT qualifier is a poor man's implementation of snapshots
> that won't work anyway if we started using qualifiers properly (unless we
> went with full Maven compatibility), because -SNAPSHOT happens to be more
> recent than -M, -R. It works for now only because we don't use
> qualifiers effectively. And it has nothing to do with Maven, -SNAPSHOT in
> Buildr 1.3.3 has no special meaning or behavior.
Actually the release task has a special behavior related to snapshot: it
eliminates the thing from the release number. Granted, not only snapshot but
anything that's not a number. I guess the original intent was related to
snapshot though.
>
>
> If we went the OSGi route, we'll get to choose from two options. One would
> be to have versioned snapshot, Buildr could add some qualifier each time
> you
> upload artifacts, say -D<timestamp> and you would use these against a
> designated repository, say only in development mode (so rake release would
> never be able to access this repository). Then you can refer to the most
> recent version by not saying anything specific in the version number. The
> other, which is what happens today, is to only use qualifiers for
> milestones
> and final releases, and just keep writing over the same artifact in
> development and no way to point to a specific snapshot version.
>
I'm personally fine with today's behavior for this. If your goal is to avoid
possible confusion, you could even use SNAPSHOT during your development and
change the number before you do a release.
As I mentioned before, I don't think this is something buildr should worry
about.
Cheers,
Matthieu
>
>
> Branches. This is a workflow we're adopting at Intalio. We're moving our
> development to Git, Git makes branching easy, so we're going to start
> developing each feature in its own branch. So I might be generating
> artifacts while working on a branch that adds one feature, Alexis might be
> working on a branch that implements a different feature, and we need to
> somehow tell these artifacts apart.
>
> But there's no sorting order, so this distinction does not belong in the
> version number, it has to be somewhere in the package name. The idea is to
> make it possible for Buildr to know it's used inside a branch, and
> incorporate that branch name into the package name, maybe as a prefix or
> suffix. So you might have assaf-ode-runtime-1.2.jar and
> alexis-ode-runtime-1.2.jar.
>
> Assaf
>
>
> On Thu, Feb 19, 2009 at 9:24 PM, Alexis Midon <al...@gmail.com>
> wrote:
>
> > Let's base the discussion on a real use case, so we can be specific:
> > I'm currently developing a new feature for ODE. This development is done
> in
> > a separate branch named FOO based on version 1.3.0-SNAPSHOT. When I'll
> > think
> > my development is good enough for testing, I'd like to release and share
> > this version of my branch.
> > But if we look at the buildfiles, both branches, 1.X and FOO, are about
> to
> > release with the same version: 1.3.0. This is really confusing and does
> not
> > denote the code differences
> >
> > so how should we handle this case?
> >
> > A few of points:
> > Personnally I think the SNAPSHOT suffix is completely useless. To me, a
> > snapshot is not different from a release and is just additional
> complexity.
> > A 3-digit version is enough.
> >
> > Qualifiers should be supported obviously. But they do not solve our case:
> > parallel developments. the conventiont is that 1.3.0 is newer than
> > 1.3.0-FOO. And this describes a sequence anyway.
> >
> > Assaf has suggested that the package name should discriminate parallel
> > developments. The branch FOO should release artifacts named like
> > ode-compiler-FOO-1.3.0, while 1.x (the main branch) releases
> > ode-compiler-1.3.0. The difference is clearly stated and do not interfer
> > with version comparaison.
> >
> >
> > On Mon, Feb 9, 2009 at 4:53 PM, Alex Boisvert <bo...@intalio.com>
> > wrote:
> >
> > > Oh, right, you mean the "qualifier".
> > >
> > > Here's what Better Builds with
> > > Maven<
> http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
> > > >says,
> > >
> > > With regard to ordering, the elements are considered in sequence to
> > > determine which is newer - first by major version, second - if the
> major
> > > versions were equal - by minor version, third by bug fix version,
> fourth
> > by
> > > qualifier (using string comparison), and finally, by build number. A
> > > version
> > > that contains a qualifier is older than a version without a qualifier;
> > for
> > > example, 1.2-beta is older than version 1.2. A version that also
> contains
> > a
> > > build number is considered newer than a version without a build number;
> > > for example, 1.2-beta-1 is newer than 1.2-beta.
> > >
> > > But my point still stands, Buildr should drop the SNAPSHOT qualifier
> (and
> > > only SNAPSHOT) during a release.
> > >
> > > alex
> > >
> > >
> > >
> > > On Mon, Feb 9, 2009 at 4:36 PM, Assaf Arkin <ar...@intalio.com> wrote:
> > >
> > > >
> > > >
> > > > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com>
> > wrote:
> > > >
> > > > Ugh? If beta is not a release but a pre-release, how do you
> > > pre-release
> > > >> a
> > > >> beta?
> > > >>
> > > >
> > > > Then maybe it's called something else, either way the fourth part is
> > > > constrained.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >>
> > > >> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com>
> > wrote:
> > > >>
> > > >> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <
> boisvert@intalio.com>
> > > >>> wrote:
> > > >>>
> > > >>> The Maven conventions don't restrict the version to only numbers,
> so
> > > >>>>
> > > >>> yeah,
> > > >>>
> > > >>>> buildr should only strip a "-SNAPSHOT" suffix.
> > > >>>>
> > > >>>
> > > >>>
> > > >>> Actually it does: releases must end with numbers, pre-releases (rc,
> > > beta,
> > > >>> etc) with alphanumerics, and therefore 0 by virtue of being a
> release
> > > is
> > > >>> higher than beta2. OSGi uses alphanumerics on the fourth part,
> other
> > > >>> package managers have their own conventions. Buildr doesn't follow
> > > >>> anything
> > > >>> more complicated than numerical.
> > > >>>
> > > >>> Assaf
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> alex
> > > >>>>
> > > >>>>
> > > >>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <
> > matthieu@offthelip.org
> > > >>>>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>
> > > >>>> Hi guys,
> > > >>>>>
> > > >>>>> The logic in release strips out any letter that comes after the
> > last
> > > >>>>>
> > > >>>> ('.'
> > > >>>
> > > >>>> +
> > > >>>>
> > > >>>>> digit) in a project release number. So something like 1.2-beta
> will
> > > >>>>> actually
> > > >>>>> be released as 1.2. Sounds to me like a bug but I just wanted to
> > > check
> > > >>>>> before that it wasn't by design, an adoption of the 'no letter in
> > > >>>>>
> > > >>>> releases'
> > > >>>>
> > > >>>>> RubyGem doctrine.
> > > >>>>>
> > > >>>>> Given that the actual goal is only to strip an ending
> "-SNAPSHOT",
> > > the
> > > >>>>>
> > > >>>> fix
> > > >>>>
> > > >>>>> is pretty straightforward.
> > > >>>>>
> > > >>>>> Cheers,
> > > >>>>> Matthieu
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > >
> >
>
Re: No beta or RC?
Posted by Assaf Arkin <ar...@intalio.com>.
There are actually three, helps to separate them, issues we have to deal
with:
1. Qualifiers, so you can make a 1.2-beta1 release and follow it with a
1.2-beta2 release. There are two approaches to qualifiers, I'll get to those
in a moment. Right now there's no support in Buildr for either one.
2. Snapshots make it easy to share artifacts you're working on right now
without overhead of making a release. A snapshot is just the most recent set
of artifacts you created.
3. Working in different branches, under the same version, and being able to
tell these artifacts apart.
The release task doesn't support 1, 2 or 3 and there was some confusing
attempting to solve all three at the same time. So the most important point
was realizing that we're looking at three things and splitting them.
Qualifiers. Developers just don't like to see version numbers go to waste,
it offends them to no end when you jump from 1.2.6 straight to 1.3.2. That
means you can't use 1.3.0 for a beta release and 1.3.1 for release
candidate, because most people would only get to see 1.3.2 as the first
1.3.x leading to horrible, possibly catastrophic results. People have been
killed for lesser crimes.
So qualifiers come to the rescue, and here we have two approaches. There's
"qualifier is just a string, and if you don't specify one, you're referring
to the most recent", which is the approach I've seen used most often. And
there's the Maven approach, which is just nuts. We don't support either one,
and we know Maven with all its rules is incompatible with OSGi and it's
single, sane, rule, and I for one would favor going the OSGi route which
means:
Qualifier is a string, sorted lexicographically.
Snapshots. The deal with snapshot is very simple. In development mode you
want to reference the most recent version of something, which could change
any minute, you might be building it from a different project, or someone
else is building it for you. You might need to get very particular, and each
snapshot release has a specific version number, but most of the time you
don't care and just want to work with the latest.
Using the -SNAPSHOT qualifier is a poor man's implementation of snapshots
that won't work anyway if we started using qualifiers properly (unless we
went with full Maven compatibility), because -SNAPSHOT happens to be more
recent than -M, -R. It works for now only because we don't use
qualifiers effectively. And it has nothing to do with Maven, -SNAPSHOT in
Buildr 1.3.3 has no special meaning or behavior.
If we went the OSGi route, we'll get to choose from two options. One would
be to have versioned snapshot, Buildr could add some qualifier each time you
upload artifacts, say -D<timestamp> and you would use these against a
designated repository, say only in development mode (so rake release would
never be able to access this repository). Then you can refer to the most
recent version by not saying anything specific in the version number. The
other, which is what happens today, is to only use qualifiers for milestones
and final releases, and just keep writing over the same artifact in
development and no way to point to a specific snapshot version.
Branches. This is a workflow we're adopting at Intalio. We're moving our
development to Git, Git makes branching easy, so we're going to start
developing each feature in its own branch. So I might be generating
artifacts while working on a branch that adds one feature, Alexis might be
working on a branch that implements a different feature, and we need to
somehow tell these artifacts apart.
But there's no sorting order, so this distinction does not belong in the
version number, it has to be somewhere in the package name. The idea is to
make it possible for Buildr to know it's used inside a branch, and
incorporate that branch name into the package name, maybe as a prefix or
suffix. So you might have assaf-ode-runtime-1.2.jar and
alexis-ode-runtime-1.2.jar.
Assaf
On Thu, Feb 19, 2009 at 9:24 PM, Alexis Midon <al...@gmail.com> wrote:
> Let's base the discussion on a real use case, so we can be specific:
> I'm currently developing a new feature for ODE. This development is done in
> a separate branch named FOO based on version 1.3.0-SNAPSHOT. When I'll
> think
> my development is good enough for testing, I'd like to release and share
> this version of my branch.
> But if we look at the buildfiles, both branches, 1.X and FOO, are about to
> release with the same version: 1.3.0. This is really confusing and does not
> denote the code differences
>
> so how should we handle this case?
>
> A few of points:
> Personnally I think the SNAPSHOT suffix is completely useless. To me, a
> snapshot is not different from a release and is just additional complexity.
> A 3-digit version is enough.
>
> Qualifiers should be supported obviously. But they do not solve our case:
> parallel developments. the conventiont is that 1.3.0 is newer than
> 1.3.0-FOO. And this describes a sequence anyway.
>
> Assaf has suggested that the package name should discriminate parallel
> developments. The branch FOO should release artifacts named like
> ode-compiler-FOO-1.3.0, while 1.x (the main branch) releases
> ode-compiler-1.3.0. The difference is clearly stated and do not interfer
> with version comparaison.
>
>
> On Mon, Feb 9, 2009 at 4:53 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
>
> > Oh, right, you mean the "qualifier".
> >
> > Here's what Better Builds with
> > Maven<http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
> > >says,
> >
> > With regard to ordering, the elements are considered in sequence to
> > determine which is newer - first by major version, second - if the major
> > versions were equal - by minor version, third by bug fix version, fourth
> by
> > qualifier (using string comparison), and finally, by build number. A
> > version
> > that contains a qualifier is older than a version without a qualifier;
> for
> > example, 1.2-beta is older than version 1.2. A version that also contains
> a
> > build number is considered newer than a version without a build number;
> > for example, 1.2-beta-1 is newer than 1.2-beta.
> >
> > But my point still stands, Buildr should drop the SNAPSHOT qualifier (and
> > only SNAPSHOT) during a release.
> >
> > alex
> >
> >
> >
> > On Mon, Feb 9, 2009 at 4:36 PM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > >
> > >
> > > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
> > >
> > > Ugh? If beta is not a release but a pre-release, how do you
> > pre-release
> > >> a
> > >> beta?
> > >>
> > >
> > > Then maybe it's called something else, either way the fourth part is
> > > constrained.
> > >
> > >
> > >
> > >
> > >
> > >>
> > >>
> > >> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com>
> wrote:
> > >>
> > >> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
> > >>> wrote:
> > >>>
> > >>> The Maven conventions don't restrict the version to only numbers, so
> > >>>>
> > >>> yeah,
> > >>>
> > >>>> buildr should only strip a "-SNAPSHOT" suffix.
> > >>>>
> > >>>
> > >>>
> > >>> Actually it does: releases must end with numbers, pre-releases (rc,
> > beta,
> > >>> etc) with alphanumerics, and therefore 0 by virtue of being a release
> > is
> > >>> higher than beta2. OSGi uses alphanumerics on the fourth part, other
> > >>> package managers have their own conventions. Buildr doesn't follow
> > >>> anything
> > >>> more complicated than numerical.
> > >>>
> > >>> Assaf
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> alex
> > >>>>
> > >>>>
> > >>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <
> matthieu@offthelip.org
> > >>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>
> > >>>> Hi guys,
> > >>>>>
> > >>>>> The logic in release strips out any letter that comes after the
> last
> > >>>>>
> > >>>> ('.'
> > >>>
> > >>>> +
> > >>>>
> > >>>>> digit) in a project release number. So something like 1.2-beta will
> > >>>>> actually
> > >>>>> be released as 1.2. Sounds to me like a bug but I just wanted to
> > check
> > >>>>> before that it wasn't by design, an adoption of the 'no letter in
> > >>>>>
> > >>>> releases'
> > >>>>
> > >>>>> RubyGem doctrine.
> > >>>>>
> > >>>>> Given that the actual goal is only to strip an ending "-SNAPSHOT",
> > the
> > >>>>>
> > >>>> fix
> > >>>>
> > >>>>> is pretty straightforward.
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Matthieu
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> >
>
Re: No beta or RC?
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Feb 19, 2009 at 9:24 PM, Alexis Midon <al...@gmail.com> wrote:
> Let's base the discussion on a real use case, so we can be specific:
> I'm currently developing a new feature for ODE. This development is done in
> a separate branch named FOO based on version 1.3.0-SNAPSHOT. When I'll
> think
> my development is good enough for testing, I'd like to release and share
> this version of my branch.
> But if we look at the buildfiles, both branches, 1.X and FOO, are about to
> release with the same version: 1.3.0. This is really confusing and does not
> denote the code differences
>
> so how should we handle this case?
>
Different branches, different base names. One is ODE, the other is ODE-FOO.
Keeps life simple :)
>
> A few of points:
> Personnally I think the SNAPSHOT suffix is completely useless. To me, a
> snapshot is not different from a release and is just additional complexity.
> A 3-digit version is enough.
>
I'm fine with snapshot as long as it stays on your machine. Make it just an
optional marker to know it's a local build. You should be free to not use it
though.
>
> Qualifiers should be supported obviously. But they do not solve our case:
> parallel developments. the conventiont is that 1.3.0 is newer than
> 1.3.0-FOO. And this describes a sequence anyway.
>
> Assaf has suggested that the package name should discriminate parallel
> developments. The branch FOO should release artifacts named like
> ode-compiler-FOO-1.3.0, while 1.x (the main branch) releases
> ode-compiler-1.3.0. The difference is clearly stated and do not interfer
> with version comparaison.
>
I'd agree although I would do ode-FOO-compiler-1.3.0. First because FOO
qualifies the whole stuff, not just a module and second because it's easier
to change: the root definition doesn't have any directory associated with
it.
Matthieu
>
>
> On Mon, Feb 9, 2009 at 4:53 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
>
> > Oh, right, you mean the "qualifier".
> >
> > Here's what Better Builds with
> > Maven<http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
> > >says,
> >
> > With regard to ordering, the elements are considered in sequence to
> > determine which is newer - first by major version, second - if the major
> > versions were equal - by minor version, third by bug fix version, fourth
> by
> > qualifier (using string comparison), and finally, by build number. A
> > version
> > that contains a qualifier is older than a version without a qualifier;
> for
> > example, 1.2-beta is older than version 1.2. A version that also contains
> a
> > build number is considered newer than a version without a build number;
> > for example, 1.2-beta-1 is newer than 1.2-beta.
> >
> > But my point still stands, Buildr should drop the SNAPSHOT qualifier (and
> > only SNAPSHOT) during a release.
> >
> > alex
> >
> >
> >
> > On Mon, Feb 9, 2009 at 4:36 PM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > >
> > >
> > > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
> > >
> > > Ugh? If beta is not a release but a pre-release, how do you
> > pre-release
> > >> a
> > >> beta?
> > >>
> > >
> > > Then maybe it's called something else, either way the fourth part is
> > > constrained.
> > >
> > >
> > >
> > >
> > >
> > >>
> > >>
> > >> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com>
> wrote:
> > >>
> > >> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
> > >>> wrote:
> > >>>
> > >>> The Maven conventions don't restrict the version to only numbers, so
> > >>>>
> > >>> yeah,
> > >>>
> > >>>> buildr should only strip a "-SNAPSHOT" suffix.
> > >>>>
> > >>>
> > >>>
> > >>> Actually it does: releases must end with numbers, pre-releases (rc,
> > beta,
> > >>> etc) with alphanumerics, and therefore 0 by virtue of being a release
> > is
> > >>> higher than beta2. OSGi uses alphanumerics on the fourth part, other
> > >>> package managers have their own conventions. Buildr doesn't follow
> > >>> anything
> > >>> more complicated than numerical.
> > >>>
> > >>> Assaf
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> alex
> > >>>>
> > >>>>
> > >>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <
> matthieu@offthelip.org
> > >>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>
> > >>>> Hi guys,
> > >>>>>
> > >>>>> The logic in release strips out any letter that comes after the
> last
> > >>>>>
> > >>>> ('.'
> > >>>
> > >>>> +
> > >>>>
> > >>>>> digit) in a project release number. So something like 1.2-beta will
> > >>>>> actually
> > >>>>> be released as 1.2. Sounds to me like a bug but I just wanted to
> > check
> > >>>>> before that it wasn't by design, an adoption of the 'no letter in
> > >>>>>
> > >>>> releases'
> > >>>>
> > >>>>> RubyGem doctrine.
> > >>>>>
> > >>>>> Given that the actual goal is only to strip an ending "-SNAPSHOT",
> > the
> > >>>>>
> > >>>> fix
> > >>>>
> > >>>>> is pretty straightforward.
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Matthieu
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> >
>
Re: No beta or RC?
Posted by Alexis Midon <al...@gmail.com>.
Let's base the discussion on a real use case, so we can be specific:
I'm currently developing a new feature for ODE. This development is done in
a separate branch named FOO based on version 1.3.0-SNAPSHOT. When I'll think
my development is good enough for testing, I'd like to release and share
this version of my branch.
But if we look at the buildfiles, both branches, 1.X and FOO, are about to
release with the same version: 1.3.0. This is really confusing and does not
denote the code differences
so how should we handle this case?
A few of points:
Personnally I think the SNAPSHOT suffix is completely useless. To me, a
snapshot is not different from a release and is just additional complexity.
A 3-digit version is enough.
Qualifiers should be supported obviously. But they do not solve our case:
parallel developments. the conventiont is that 1.3.0 is newer than
1.3.0-FOO. And this describes a sequence anyway.
Assaf has suggested that the package name should discriminate parallel
developments. The branch FOO should release artifacts named like
ode-compiler-FOO-1.3.0, while 1.x (the main branch) releases
ode-compiler-1.3.0. The difference is clearly stated and do not interfer
with version comparaison.
On Mon, Feb 9, 2009 at 4:53 PM, Alex Boisvert <bo...@intalio.com> wrote:
> Oh, right, you mean the "qualifier".
>
> Here's what Better Builds with
> Maven<http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf
> >says,
>
> With regard to ordering, the elements are considered in sequence to
> determine which is newer - first by major version, second - if the major
> versions were equal - by minor version, third by bug fix version, fourth by
> qualifier (using string comparison), and finally, by build number. A
> version
> that contains a qualifier is older than a version without a qualifier; for
> example, 1.2-beta is older than version 1.2. A version that also contains a
> build number is considered newer than a version without a build number;
> for example, 1.2-beta-1 is newer than 1.2-beta.
>
> But my point still stands, Buildr should drop the SNAPSHOT qualifier (and
> only SNAPSHOT) during a release.
>
> alex
>
>
>
> On Mon, Feb 9, 2009 at 4:36 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
> >
> >
> > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > Ugh? If beta is not a release but a pre-release, how do you
> pre-release
> >> a
> >> beta?
> >>
> >
> > Then maybe it's called something else, either way the fourth part is
> > constrained.
> >
> >
> >
> >
> >
> >>
> >>
> >> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> >>
> >> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
> >>> wrote:
> >>>
> >>> The Maven conventions don't restrict the version to only numbers, so
> >>>>
> >>> yeah,
> >>>
> >>>> buildr should only strip a "-SNAPSHOT" suffix.
> >>>>
> >>>
> >>>
> >>> Actually it does: releases must end with numbers, pre-releases (rc,
> beta,
> >>> etc) with alphanumerics, and therefore 0 by virtue of being a release
> is
> >>> higher than beta2. OSGi uses alphanumerics on the fourth part, other
> >>> package managers have their own conventions. Buildr doesn't follow
> >>> anything
> >>> more complicated than numerical.
> >>>
> >>> Assaf
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> alex
> >>>>
> >>>>
> >>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <matthieu@offthelip.org
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>
> >>>> Hi guys,
> >>>>>
> >>>>> The logic in release strips out any letter that comes after the last
> >>>>>
> >>>> ('.'
> >>>
> >>>> +
> >>>>
> >>>>> digit) in a project release number. So something like 1.2-beta will
> >>>>> actually
> >>>>> be released as 1.2. Sounds to me like a bug but I just wanted to
> check
> >>>>> before that it wasn't by design, an adoption of the 'no letter in
> >>>>>
> >>>> releases'
> >>>>
> >>>>> RubyGem doctrine.
> >>>>>
> >>>>> Given that the actual goal is only to strip an ending "-SNAPSHOT",
> the
> >>>>>
> >>>> fix
> >>>>
> >>>>> is pretty straightforward.
> >>>>>
> >>>>> Cheers,
> >>>>> Matthieu
> >>>>>
> >>>>>
> >>>>
> >>>
>
Re: No beta or RC?
Posted by Alex Boisvert <bo...@intalio.com>.
Oh, right, you mean the "qualifier".
Here's what Better Builds with
Maven<http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf>says,
With regard to ordering, the elements are considered in sequence to
determine which is newer - first by major version, second - if the major
versions were equal - by minor version, third by bug fix version, fourth by
qualifier (using string comparison), and finally, by build number. A version
that contains a qualifier is older than a version without a qualifier; for
example, 1.2-beta is older than version 1.2. A version that also contains a
build number is considered newer than a version without a build number;
for example, 1.2-beta-1 is newer than 1.2-beta.
But my point still stands, Buildr should drop the SNAPSHOT qualifier (and
only SNAPSHOT) during a release.
alex
On Mon, Feb 9, 2009 at 4:36 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
>
> On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com> wrote:
>
> Ugh? If beta is not a release but a pre-release, how do you pre-release
>> a
>> beta?
>>
>
> Then maybe it's called something else, either way the fourth part is
> constrained.
>
>
>
>
>
>>
>>
>> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
>>
>> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
>>> wrote:
>>>
>>> The Maven conventions don't restrict the version to only numbers, so
>>>>
>>> yeah,
>>>
>>>> buildr should only strip a "-SNAPSHOT" suffix.
>>>>
>>>
>>>
>>> Actually it does: releases must end with numbers, pre-releases (rc, beta,
>>> etc) with alphanumerics, and therefore 0 by virtue of being a release is
>>> higher than beta2. OSGi uses alphanumerics on the fourth part, other
>>> package managers have their own conventions. Buildr doesn't follow
>>> anything
>>> more complicated than numerical.
>>>
>>> Assaf
>>>
>>>
>>>
>>>
>>>>
>>>> alex
>>>>
>>>>
>>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <matthieu@offthelip.org
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> Hi guys,
>>>>>
>>>>> The logic in release strips out any letter that comes after the last
>>>>>
>>>> ('.'
>>>
>>>> +
>>>>
>>>>> digit) in a project release number. So something like 1.2-beta will
>>>>> actually
>>>>> be released as 1.2. Sounds to me like a bug but I just wanted to check
>>>>> before that it wasn't by design, an adoption of the 'no letter in
>>>>>
>>>> releases'
>>>>
>>>>> RubyGem doctrine.
>>>>>
>>>>> Given that the actual goal is only to strip an ending "-SNAPSHOT", the
>>>>>
>>>> fix
>>>>
>>>>> is pretty straightforward.
>>>>>
>>>>> Cheers,
>>>>> Matthieu
>>>>>
>>>>>
>>>>
>>>
Re: No beta or RC?
Posted by Assaf Arkin <ar...@intalio.com>.
On Feb 9, 2009, at 4:16 PM, Alex Boisvert <bo...@intalio.com> wrote:
> Ugh? If beta is not a release but a pre-release, how do you pre-
> release a
> beta?
Then maybe it's called something else, either way the fourth part is
constrained.
>
>
>
> On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com>
> wrote:
>
>> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
>> wrote:
>>
>>> The Maven conventions don't restrict the version to only numbers, so
>> yeah,
>>> buildr should only strip a "-SNAPSHOT" suffix.
>>
>>
>> Actually it does: releases must end with numbers, pre-releases (rc,
>> beta,
>> etc) with alphanumerics, and therefore 0 by virtue of being a
>> release is
>> higher than beta2. OSGi uses alphanumerics on the fourth part, other
>> package managers have their own conventions. Buildr doesn't follow
>> anything
>> more complicated than numerical.
>>
>> Assaf
>>
>>
>>
>>>
>>>
>>> alex
>>>
>>>
>>> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou
>>> <matthieu@offthelip.org
>>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> The logic in release strips out any letter that comes after the
>>>> last
>> ('.'
>>> +
>>>> digit) in a project release number. So something like 1.2-beta will
>>>> actually
>>>> be released as 1.2. Sounds to me like a bug but I just wanted to
>>>> check
>>>> before that it wasn't by design, an adoption of the 'no letter in
>>> releases'
>>>> RubyGem doctrine.
>>>>
>>>> Given that the actual goal is only to strip an ending "-
>>>> SNAPSHOT", the
>>> fix
>>>> is pretty straightforward.
>>>>
>>>> Cheers,
>>>> Matthieu
>>>>
>>>
>>
Re: No beta or RC?
Posted by Alex Boisvert <bo...@intalio.com>.
Ugh? If beta is not a release but a pre-release, how do you pre-release a
beta?
On Sun, Feb 8, 2009 at 10:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
>
> > The Maven conventions don't restrict the version to only numbers, so
> yeah,
> > buildr should only strip a "-SNAPSHOT" suffix.
>
>
> Actually it does: releases must end with numbers, pre-releases (rc, beta,
> etc) with alphanumerics, and therefore 0 by virtue of being a release is
> higher than beta2. OSGi uses alphanumerics on the fourth part, other
> package managers have their own conventions. Buildr doesn't follow
> anything
> more complicated than numerical.
>
> Assaf
>
>
>
> >
> >
> > alex
> >
> >
> > On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <matthieu@offthelip.org
> > >wrote:
> >
> > > Hi guys,
> > >
> > > The logic in release strips out any letter that comes after the last
> ('.'
> > +
> > > digit) in a project release number. So something like 1.2-beta will
> > > actually
> > > be released as 1.2. Sounds to me like a bug but I just wanted to check
> > > before that it wasn't by design, an adoption of the 'no letter in
> > releases'
> > > RubyGem doctrine.
> > >
> > > Given that the actual goal is only to strip an ending "-SNAPSHOT", the
> > fix
> > > is pretty straightforward.
> > >
> > > Cheers,
> > > Matthieu
> > >
> >
>
Re: No beta or RC?
Posted by Assaf Arkin <ar...@intalio.com>.
On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert <bo...@intalio.com> wrote:
> The Maven conventions don't restrict the version to only numbers, so yeah,
> buildr should only strip a "-SNAPSHOT" suffix.
Actually it does: releases must end with numbers, pre-releases (rc, beta,
etc) with alphanumerics, and therefore 0 by virtue of being a release is
higher than beta2. OSGi uses alphanumerics on the fourth part, other
package managers have their own conventions. Buildr doesn't follow anything
more complicated than numerical.
Assaf
>
>
> alex
>
>
> On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <matthieu@offthelip.org
> >wrote:
>
> > Hi guys,
> >
> > The logic in release strips out any letter that comes after the last ('.'
> +
> > digit) in a project release number. So something like 1.2-beta will
> > actually
> > be released as 1.2. Sounds to me like a bug but I just wanted to check
> > before that it wasn't by design, an adoption of the 'no letter in
> releases'
> > RubyGem doctrine.
> >
> > Given that the actual goal is only to strip an ending "-SNAPSHOT", the
> fix
> > is pretty straightforward.
> >
> > Cheers,
> > Matthieu
> >
>
Re: No beta or RC?
Posted by Alex Boisvert <bo...@intalio.com>.
The Maven conventions don't restrict the version to only numbers, so yeah,
buildr should only strip a "-SNAPSHOT" suffix.
alex
On Fri, Feb 6, 2009 at 2:35 PM, Matthieu Riou <ma...@offthelip.org>wrote:
> Hi guys,
>
> The logic in release strips out any letter that comes after the last ('.' +
> digit) in a project release number. So something like 1.2-beta will
> actually
> be released as 1.2. Sounds to me like a bug but I just wanted to check
> before that it wasn't by design, an adoption of the 'no letter in releases'
> RubyGem doctrine.
>
> Given that the actual goal is only to strip an ending "-SNAPSHOT", the fix
> is pretty straightforward.
>
> Cheers,
> Matthieu
>