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 <alexismi...@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 <boisv...@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 <boisv...@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 <boisv...@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 < > matth...@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 > > >>>>> > > >>>>> > > >>>> > > >>> > > >
