On Fri, Feb 20, 2009 at 1:14 AM, Assaf Arkin <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> wrote: > > > > > > > > > > > > > > > On Feb 9, 2009, at 4:16 PM, Alex Boisvert <[email protected]> > > 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 <[email protected]> > > wrote: > > > >> > > > >> On Fri, Feb 6, 2009 at 2:51 PM, Alex Boisvert < > [email protected]> > > > >>> 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 < > > [email protected] > > > >>>> > > > >>>>> 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 > > > >>>>> > > > >>>>> > > > >>>> > > > >>> > > > > > >
