buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Riou <matthieu.r...@gmail.com>
Subject Re: No beta or RC?
Date Fri, 20 Feb 2009 16:44:22 GMT
On Fri, Feb 20, 2009 at 1:14 AM, Assaf Arkin <arkin@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 <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