buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@intalio.com>
Subject Re: No beta or RC?
Date Fri, 20 Feb 2009 09:14:11 GMT
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 <alexismidon@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 <boisvert@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 <arkin@intalio.com> wrote:
> >
> > >
> > >
> > > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <boisvert@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 <arkin@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
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message