On Fri, Jun 13, 2008 at 8:48 AM, ant elder <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 9:41 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > Luciano Resende wrote: > > >> > > >> How about 1.5-SNAPSHOT ? This would probably give us some room to have > > >> couple releases without the necessity to keep updating the trunk pom > > >> version. And this would probably make everybody happy :) > > >> > > >> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]> > wrote: > > >>> > > >>> On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende < > [EMAIL PROTECTED]> > > >>> wrote: > > >>> > > >>>> I guess part of problem here is because a lot of people assume that > > >>>> the maven artifact version represents what is going to be our next > > >>>> release and then, if it's set as 2.0-SNAPSHOT, it means our next > > >>>> release would be 2.0. > > >>> > > >>> I agree, this is exactly the issue. But I'm not sure its that much of > > an > > >>> unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT > as > > >>> the > > >>> trunk version before there has been any decision to start working on > a > > >>> 2.0 > > >>> in trunk. > > >>> > > >>> ...ant > > >>> > > >> > > >> > > >> > > > > > > I'd prefer the next logical number, 1.3 for example. > > > > > > > I still think plain SNAPSHOT would be simplest but as no one else seems > to > > like that I think I agree with this - the next logical number seems > better > > than things like 1.x or 2.0 etc. So, I plan to change trunk to > 1.4-SNAPSHOT > > when the 1.3 branch is taken, do say if you really don't like this but > its > > what we've been doing most of the time in the past so i hope most can > live > > with it. > > > > ...ant > > > > > I've been asked off list to highlight an issue that may not have been clear > from whats already been said in this thread. > > If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to > date with the latest code will use that version in their dependencies. They > may not pay that close attention to the dev list so when we create the > branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the > users > dependencies will still use 1.4-SNAPSHOT but now instead of getting the > latest code they're getting the stable branch code. One way this could be > avoided is by using a trunk version of simply "SNAPSHOT". Is anyone really > against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? > > ...ant > There is maybe a reason why this conversation has been problematic. Two conflicting requirements Requirement1: Avoid us updating trunk poms everytime we do a release. Consequently avoid snapshot users updating their poms Requirement2: Clearly identify that artifacts are SPI compatible with the 1.X stream of development. Solution1: Change artifact version to SNAPSHOT (R1 = Y, R2 = N) Solution1a: if we do start incompatible developement 1.X development will stop (R1 = Y, R2 = Y) Solution1b: if we do start incompatible developement 1.X development will continue in a specifically versioned branch 1.4-SNAPSHOT (R1 = Y, R2 = Y) Solution1c: if we do start incompatible development it will be under a different group id (R1 = Y, R2 = Y) Solution2: Change artifact version to 1.4-SNAPSHOT (R1 = N, R2 = Y) Solution3: Change artifact version to 1.X-SNAPSHOT (R1 = Y, R2 = Y) I am NOT promoting that we start incompatible development. I'm pointing out that the thought has an impact on this issue. We have discussed 2.0 on the list before and I believe the sentiment is we go as far as we can with 1.X with people innovating in their sandboxes and merging back into 1.X trunk. There may be some new feature/organization/thought/philosophy/sentiment/architecture etc. that someone comes up with down the line that means this isn't possible. At that point we have to decide if we want that piece badly enough to start 2.0. Simon.
