Re: 2.8.0/2.8.1 Binary incompatibility of RichInt#until(Int)

On Tue, Sep 7, 2010 at 11:51 AM, Josh Suereth wrote:
> My gut says to go with trunk-SNAPSHOT or devel-SNAPSHOT.  Most projects do
> pick a version number for trunk to target, so scala is the "odd man out"
> here.
>
> Also, it is important that the 2.8.1 branch have nightly snapshots for the
> community to consume.  I would also argue that when trunk receives a target
> version, the nightly snapshots should use this version.

I'd like to see nightly snapshots of 2.8.1 (as soon a possible really,
otherwise it's fiddly for me to set up Hudson builds of the Scala IDE
relative to 2.8.1) ... but they really have to be distinguishable from
nightly snapshots of trunk.

I don't think that trunk-SNAPSHOT or devel-SNAPSHOT work for trunk
builds either ... there are too many tools which depend on the Scala
and compiler library versions being in x.y.z-qualifier form (I think
probably even the Maven Scala plugin, and I'm fairly sure that Tycho
would choke on trunk-SNAPSHOT).

My vote is for Mark's proposal of 2.8.9999-SNAPSHOT for trunk and
2.8.1-SNAPSHOT for builds from the 2.8.x branch leading up to
2.8.1.final.

Cheers,

Miles

Actually, as Miles states, devel-SNAPSHOST or trunk-SNAPSHOT would mess up the maven-scala-plugin's "determine flags/features from scala version" code.  Part of this is that we need to be able to determine if a particular version is "after 2.8" or "after 2.7.4" or whatever.  
Is it at all possible for LAMP to decide on a version number for trunk ahead of time, or just use something "high", like 2.9 or 3.0?   I can understand not knowing if trunk will be a 2.9 or a 3.0, but I think it's ok to use 2.9 snapshots and later decide on a 3.0 release.   However using a 3.0 for trunk and then deciding on 2.9 could be more dangerous, due to the comparison on versions failing suddenly.  Also, if the 2.8.x branches are all supposed to be binary compatible, I highly doubt trunk will have a 2.8 version number, therefore why not bump it to 2.9?   With the backporting scheme going on for 2.8.1, I think this makes a lot of sense.
Thanks Miles for reminding me of the tool-versioning issue.   Nexus would actually be ok with devel-SNAPSHOT, but a lot of other tools would fail.
- Josh

On Tue, Sep 7, 2010 at 7:04 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Sep 7, 2010 at 11:51 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> My gut says to go with trunk-SNAPSHOT or devel-SNAPSHOT.  Most projects do
> pick a version number for trunk to target, so scala is the "odd man out"
> here.
>
> Also, it is important that the 2.8.1 branch have nightly snapshots for the
> community to consume.  I would also argue that when trunk receives a target
> version, the nightly snapshots should use this version.

I'd like to see nightly snapshots of 2.8.1 (as soon a possible really,
otherwise it's fiddly for me to set up Hudson builds of the Scala IDE
relative to 2.8.1) ... but they really have to be distinguishable from
nightly snapshots of trunk.

I don't think that trunk-SNAPSHOT or devel-SNAPSHOT work for trunk
builds either ... there are too many tools which depend on the Scala
and compiler library versions being in x.y.z-qualifier form (I think
probably even the Maven Scala plugin, and I'm fairly sure that Tycho
would choke on trunk-SNAPSHOT).

My vote is for Mark's proposal of 2.8.9999-SNAPSHOT for trunk and
2.8.1-SNAPSHOT for builds from the 2.8.x branch leading up to
2.8.1.final.

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Josh Suereth wrote:
> Actually, as Miles states, devel-SNAPSHOST or trunk-SNAPSHOT would mess up
> the maven-scala-plugin's "determine flags/features from scala version" code.
> Part of this is that we need to be able to determine if a particular
> version is "after 2.8" or "after 2.7.4" or whatever.
>
> Is it at all possible for LAMP to decide on a version number for trunk ahead
> of time, or just use something "high", like 2.9 or 3.0? I can understand
> not knowing if trunk will be a 2.9 or a 3.0, but I think it's ok to use 2.9
> snapshots and later decide on a 3.0 release. However using a 3.0 for trunk
> and then deciding on 2.9 could be more dangerous, due to the comparison on
> versions failing suddenly. Also, if the 2.8.x branches are all supposed to
> be binary compatible, I highly doubt trunk will have a 2.8 version number,
> therefore why not bump it to 2.9? With the backporting scheme going on for
> 2.8.1, I think this makes a lot of sense.
>
> Thanks Miles for reminding me of the tool-versioning issue. Nexus would
> actually be ok with devel-SNAPSHOT, but a lot of other tools would fail.
>

Hey Josh,

I am not sure that relying on a version number comparison of this sort
makes sense. The stuff that is in trunk is not necessarily related to any
future release at all: features and code may be added or removed pretty
arbitrarily at any given time in trunk.

I know little about the workings of Maven, but why would anyone want to use
both trunk snapshots and stable releases relying on version number
comparison alone? At this stage, for instance, we already know trunk will
be different from any 2.8.x, and probably from any 2.9.x. If anyone had
used trunk until now, and assumed 2.8.1 would be "forward" in any
direction, that would be incorrect. It's only "forward" with respect to 2.8.0.

Conversely, consider that we have the 2.7.x and 2.8.x branches, and it
makes sense to set the version number on those in order to have proper
2.8.x-SNAPSHOT versions, which are indeed comparable with what is coming
up. We can easily push out a snapshot for the upcoming 2.8.x, and one for
trunk.

My take concerning trunk is that we should really pick an arbitrary number
or identifier, and never change it again. We can go for something obvious
like "0.0.0.trunk" (to match "n.n.n.RCx"). The version suffix is never used
in nightlies, so the version would look like "0.0.0.r22943-b20100907122909".

For the record, Scala also builds just fine by specifying:
version.minor=
version.patch=
version.suffix=
version.major=trunk

The result is:
$ ./scala
Welcome to Scala version trunk...r22943-b20100907122909 (Java HotSpot(TM)
Server VM, Java 1.5.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

Concerning Maven, I understand that the identifier used in the repository
does not need to be related to the actual version number. Assuming one does
not mix trunk and releases, would something like "0.0.0-SNAPSHOT" work? (I
still like "trunk-SNAPSHOT" better, though :)

I am not knowledgeable in the mysteries of Maven, so I'll let you come up
with a suitable scheme to solve this conundrum. In any case, I can promise
that trunk and releases will almost invariably be different and not
directly comparable, moving forward. But we will keep our 2.8.x/2.9.x/etc
branches in order to reflect upcoming releases.

Toni

On Tue, Sep 7, 2010 at 11:28 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

Josh Suereth wrote:

<snip/>

Hey Josh,

I am not sure that relying on a version number comparison of this sort makes sense. The stuff that is in trunk is not necessarily related to any future release at all: features and code may be added or removed pretty arbitrarily at any given time in trunk.

Wouldn't it make more sense to put experimental features on a branch and sync that to trunk when "releasable"?   I think the trunk policy that exists in Scala is on somewhat dangerous grounds here.   The whole community may benefit from a slightly more formal development process.
 

I know little about the workings of Maven, but why would anyone want to use both trunk snapshots and stable releases relying on version number comparison alone? At this stage, for instance, we already know trunk will be different from any 2.8.x, and probably from any 2.9.x. If anyone had used trunk until now, and assumed 2.8.1 would be "forward" in any direction, that would be incorrect. It's only "forward" with respect to 2.8.0.

Think in terms of what flags/classes you need to use when instantiating scaladoc, the REPL etc.   These are what Maven uses a version number to distinguish between.  SO assuming "devel-SNAPSHOT" is always the 'largest' would work as a hack, but not ideal.   Others, like Tycho, use the version number to automatically determine what the "newest" library is and these numbers are actually enforced in meta data.   For example, in OSGi you can (and should) specify what versions your code will support.  For example, if 2.8.x release *are* binary compatible, I can release a plugin that requires scala version [2.8.0, 2.9.0).   However, by not specifying a version, you're making life hellish for Miles or any other OSGi developer that may or may not use version range restrictions.    OSGi also has an implicit "later" version algorithm it uses  to determine how it can utilize the "latest" bundle of something.   OSGi could technically run several different versions of Scala separated by classloaders, and all OSGi plugins could use explicit versions, but this is less than idea.   I also think Tycho automatically constructs a Scala version from the M.m.p-SNAPSHOT maven version.   So although theoretically not having a version would work, it would destroy Tyhco usage.  (P.S.  Tycho => Maven adapted for easier eclipse builds).  

Conversely, consider that we have the 2.7.x and 2.8.x branches, and it makes sense to set the version number on those in order to have proper 2.8.x-SNAPSHOT versions, which are indeed comparable with what is coming up. We can easily push out a snapshot for the upcoming 2.8.x, and one for trunk.

Good, I think we should always be pushing snapshots for every branch-that-will-become-a-release.   The branches that are just experiments or are designed to merge into trunk are not needed as snapshots as much.  

My take concerning trunk is that we should really pick an arbitrary number or identifier, and never change it again. We can go for something obvious like "0.0.0.trunk" (to match "n.n.n.RCx"). The version suffix is never used in nightlies, so the version would look like "0.0.0.r22943-b20100907122909".

For the record, Scala also builds just fine by specifying:
version.minor=
version.patch=
version.suffix=
version.major=trunk

This wouldn't actually work well with the OSGi/Tycho related versioning, from what I recall.   Miles can correct me, as I think he stand knee-deep in OSGi and I'm trying to pull from memory.  

The result is:
$ ./scala
Welcome to Scala version trunk...r22943-b20100907122909 (Java HotSpot(TM) Server VM, Java 1.5.0_22).
Type in expressions to have them evaluated.
Type :help for more information.


Concerning Maven, I understand that the identifier used in the repository does not need to be related to the actual version number. Assuming one does not mix trunk and releases, would something like "0.0.0-SNAPSHOT" work? (I still like "trunk-SNAPSHOT" better, though :)

I am not knowledgeable in the mysteries of Maven, so I'll let you come up with a suitable scheme to solve this conundrum. In any case, I can promise that trunk and releases will almost invariably be different and not directly comparable, moving forward. But we will keep our 2.8.x/2.9.x/etc branches in order to reflect upcoming releases.

In this case, it's more how the tools are using the version number.   The maven-scala-plugin actually supports building scala 2.6.0 (or earlier) up to 2.8.x.   We need a semi-reliable mechanism of determining how to instantiate the appropriate compiler/scaladoc/REPL.  The 0.0.0 fix would work for us, but I'll have to add patch to the maven-scala-plugin to support this directly.   I'm not so sure this will work well with Tycho and Eclipse.   Miles should be the authority on this though.

- Josh

On Tue, Sep 7, 2010 at 6:51 PM, Josh Suereth wrote:
>> For the record, Scala also builds just fine by specifying:
>> version.minor=
>> version.patch=
>> version.suffix=
>> version.major=trunk
>>
>
> This wouldn't actually work well with the OSGi/Tycho related versioning,
> from what I recall.   Miles can correct me, as I think he stand knee-deep in
> OSGi and I'm trying to pull from memory.

Yes, it would be a pain.

I would have to make up a version number, in which case I'd pick the
one Mark suggested for Maven ... 2.8.9999-SNAPSHOT (which Tycho maps
to an OSGi version number with a timestamp suffix).

Presumably other people would have to do something similar and there's
no guarantee that we'd all do it the same way ... it'd be nice if EPFL
could coordinate by picking something sensible.

Cheers,

Miles

I don't want to be flogging a dead horse here, but the current
situation really isn't very satisfactory.

I hadn't realize that the trunk version number had already been
switched to 2.8.1-SNAPSHOT and that 2.8.0-SNAPSHOT was essentially
dead (in the sense of no longer reflecting updates to trunk) as of the
2nd of September. I only realized when it became obvious that changes
that I was expecting to see in trunk weren't materializing in the
binary artifact on scala-tools.org. Maybe I'm the only one this has
affected, but I suspect I'm probably not alone.

The current numbering scheme is simply wrong. 2.8.1-SNAPSHOT is
supposed to be mean "something leading up to 2.8.1". Trunk isn't that,
it's already (always has been) past what 2.8.1 will be when released.
2.8.1-SNAPSHOT would be the correct version number for builds from the
2.8.x branch (which we really need to start seeing pushed to
scala-tools.org ASAP).

That still leaves the question of what the trunk version number ought
to be. As I've said, my vote is for 2.8.9999-SNAPSHOT, but whatever it
is it really shouldn't be 2.8.1-SNAPSHOT.

A question for Josh: now that 2.8.0-SNAPSHOT is dead, should it remain
on the scala-tools.org repo at all?

Cheers,

Miles

On Thu, Sep 9, 2010 at 10:13 AM, Miles Sabin <miles@milessabin.com> wrote:

<snip/>

A question for Josh: now that 2.8.0-SNAPSHOT is dead, should it remain
on the scala-tools.org repo at all?

There's an automated cron job that will clean it up after a few months.  I can force it if it's causing issues.   We are currently experiencing issues with nexus, so it wouldn't surprise me if this hadn't been running recently. 

On Thu, Sep 9, 2010 at 3:29 PM, Josh Suereth wrote:
> There's an automated cron job that will clean it up after a few months.  I
> can force it if it's causing issues.   We are currently experiencing issues
> with nexus, so it wouldn't surprise me if this hadn't been running
> recently.

The issue is that it's not a build that anyone would want to be using:
it's trunk as of 2010-09-02 and will never be updated to a more recent
trunk build because they're now being (mis-)labelled as
2.8.1-SNAPSHOT.

If anyone else is still pointing at 2.8.0-SNAPSHOT expecting to be
trunk, they'd be better of seeing an error report than getting
something stale.

Cheers,

Miles

Hello Miles,

As discussed in one of the previous messages, I agree with you that
"2.8.(something)-SNAPSHOT" or, better, "2.8-SNAPSHOT" should only be used
for snapshots from the 2.8.x branch. The version number in trunk will be
changed for good to "0.0.0" or similar, in order to avoid future confusion.

Josh mentioned that he needs to make some changes to the Maven support
files in order to support the new scheme. It should be reiterated that,
although at EPFL we do publish releases to the scala-tools repository, we
only do so by blindly running the scripts that the Maven community provided
us with: we have little idea of what that even does! :)

It would be great, therefore, if you and Josh could discuss the necessary
changes to the Maven support files in order to support the new scheme.

Once those changes are in place, we will change the version number in trunk
to "0.0.0", and we will start pushing the 2.8.x snapshots instead using
"2.8-SNAPSHOT", or another identifier that you will tell us to use during
the life of the 2.8.x branch. Similarly, we will push trunk using a new
identifier that you will recommend (for example, "0.0.0-SNAPSHOT", or
"0.0.0-trunk", or similar), and again we will not change that for the
foreseeable future.

Hope this plan can fulfill the needs of Maven community! Since we don't use
it here, it's a bit difficult for us to tell exactly what technical
restrictions might be involved in any given naming scheme, on Maven's side.

Toni

Miles Sabin wrote:
> I don't want to be flogging a dead horse here, but the current
> situation really isn't very satisfactory.
>
> I hadn't realize that the trunk version number had already been
> switched to 2.8.1-SNAPSHOT and that 2.8.0-SNAPSHOT was essentially
> dead (in the sense of no longer reflecting updates to trunk) as of the
> 2nd of September. I only realized when it became obvious that changes
> that I was expecting to see in trunk weren't materializing in the
> binary artifact on scala-tools.org. Maybe I'm the only one this has
> affected, but I suspect I'm probably not alone.
>
> The current numbering scheme is simply wrong. 2.8.1-SNAPSHOT is
> supposed to be mean "something leading up to 2.8.1". Trunk isn't that,
> it's already (always has been) past what 2.8.1 will be when released.
> 2.8.1-SNAPSHOT would be the correct version number for builds from the
> 2.8.x branch (which we really need to start seeing pushed to
> scala-tools.org ASAP).
>
> That still leaves the question of what the trunk version number ought
> to be. As I've said, my vote is for 2.8.9999-SNAPSHOT, but whatever it
> is it really shouldn't be 2.8.1-SNAPSHOT.
>
> A question for Josh: now that 2.8.0-SNAPSHOT is dead, should it remain
> on the scala-tools.org repo at all?
>
> Cheers,
>
>
> Miles
>

On Thu, Sep 9, 2010 at 3:34 PM, Antonio Cunei wrote:
> Josh mentioned that he needs to make some changes to the Maven support files
> in order to support the new scheme. It should be reiterated that, although
> at EPFL we do publish releases to the scala-tools repository, we only do so
> by blindly running the scripts that the Maven community provided us with: we
> have little idea of what that even does! :)
>
> It would be great, therefore, if you and Josh could discuss the necessary
> changes to the Maven support files in order to support the new scheme.

Josh? Given that 2.8.1 is approaching rapidly this is getting quite urgent.

Cheers,

Miles

Woah.   Ok, so the scripts inside of Scala is ok.  The only changes required would have to be made in the maven-scala-plugin itself, and we should investigate which versions work well in Tycho.   No changes are needed to scala's source for this change, besides picking a version number.
Now, we've had two suggestions that haven't been shot down completely:
1)  Calling trunk version 0.0.0  and modifying the tools to support this.  I"m not sure that SBT would have to change at all, but I know the maven-scala-plugin would.   I can make the changes to the maven-scala-pluign if/when this occurs. 2)  Calling trunk 2.8.999.   This would require no changes (temporarily) to any tools AFAICT but seems a poor long-term choice.   
I'd all suggest that picking a target version for trunk is a very good practice to have.   Having trunk as an unknown version implies that it is directionless, when in fact this is not the case.   Although features may be added or removed, trunk is usually the basis for whatever branch is made for the "next scala release" (i.e. 2.8, 2.9).   I think people expect some volatility in a trunk, so this should not dissuade the Scala team from assigning a "target" for trunk.   It's not a "requirement" that trunk meet the target, just a hope, shall we say.    It doesn't change the flexibility in what goes into a release at all, it's merely a target and a goal.   It would also help solve this issue immediately with no action on the community, as this is the versioning scheme expected on most open source projects.
In any case, as I don't expect EPFL to change its development paradigm overnight, can the folks on this list choose between 1 and 2?   If 1, Miles I will have a branch of the maven-scala-plugin for you tonight to test against tycho.  I'll try to also publish a snapshot of trunk @ 0.0.0-SNAPSHOT on scala-tools so you can try out the whole tool-chain.
- Josh
On Thu, Sep 9, 2010 at 10:38 AM, Miles Sabin <miles@milessabin.com> wrote:

On Thu, Sep 9, 2010 at 3:34 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:
> Josh mentioned that he needs to make some changes to the Maven support files
> in order to support the new scheme. It should be reiterated that, although
> at EPFL we do publish releases to the scala-tools repository, we only do so
> by blindly running the scripts that the Maven community provided us with: we
> have little idea of what that even does! :)
>
> It would be great, therefore, if you and Josh could discuss the necessary
> changes to the Maven support files in order to support the new scheme.

Josh? Given that 2.8.1 is approaching rapidly this is getting quite urgent.

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Thu, Sep 9, 2010 at 4:25 PM, Josh Suereth wrote:
> 2)  Calling trunk 2.8.999.   This would require no changes (temporarily) to
> any tools AFAICT but seems a poor long-term choice.
>
> I'd all suggest that picking a target version for trunk is a very good
> practice to have.   Having trunk as an unknown version implies that it is
> directionless, when in fact this is not the case.   Although features may be
> added or removed, trunk is usually the basis for whatever branch is made for
> the "next scala release" (i.e. 2.8, 2.9).

My take on option (2) is precisely the one you've stated as good
practice: a target version for trunk to aim at. I don't much care
whether it's 2.9 or 2.8.9999 or whatever, so long as it's greater than
2.8.1.

Anyhow, option (2) in some form gets my vote ...

Cheers,

Miles

On Thu, Sep 09, 2010 at 05:00:06PM +0100, Miles Sabin said
> On Thu, Sep 9, 2010 at 4:25 PM, Josh Suereth wrote:
> > 2)  Calling trunk 2.8.999.   This would require no changes (temporarily) to
> > any tools AFAICT but seems a poor long-term choice.
> >
> > I'd all suggest that picking a target version for trunk is a very good
> > practice to have.   Having trunk as an unknown version implies that it is
> > directionless, when in fact this is not the case.   Although features may be
> > added or removed, trunk is usually the basis for whatever branch is made for
> > the "next scala release" (i.e. 2.8, 2.9).
>
> My take on option (2) is precisely the one you've stated as good
> practice: a target version for trunk to aim at. I don't much care
> whether it's 2.9 or 2.8.9999 or whatever, so long as it's greater than
> 2.8.1.
>
> Anyhow, option (2) in some form gets my vote ...

+1

It seems clear to me that 2.8.9999 isn't appropriate for trunk since
2.8.9999, if there ever would be such a thing would be made from the
2.8.x branch.

Each branch (including trunk) should be a SNAPSHOT rev for the next
release to be made with that ancestry. That is, the 2.8.x branch should
be 2.8.1-SNAPSHOT and changed to 2.8.2-SNAPSHOT once 2.8.1 is released.
Since presumably the next release to be forked off trunk right now is
2.9.0, then trunk should be 2.9.0-SNAPSHOT. If at some point Martin
decides to skip 2.9.x and go straight to 3.0.0 then trunk should be made
3.0.0-SNAPSHOT. Otherwise, when and if a branch is made for stabilizing
2.9.0 (i.e. a 2.9.x branch) then that branch should be 2.9.0-SNAPSHOT
and trunk should be made 3.0.0-SNAPSHOT or 2.10.0-SNAPSHOT. To me, this
is the most predictable and reasonable way to go.

On Thu, September 9, 2010 5:25 pm, Josh Suereth wrote:
>
> 1) Calling trunk version 0.0.0 and modifying the tools to support this.
> I"m not sure that SBT would have to change at all, but I know the
> maven-scala-plugin would. I can make the changes to the
> maven-scala-pluign
> if/when this occurs.
> 2) Calling trunk 2.8.999. This would require no changes (temporarily)
> to
> any tools AFAICT but seems a poor long-term choice.
>
> I'd all suggest that picking a target version for trunk is a very good
> practice to have. Having trunk as an unknown version implies that it is
> directionless, when in fact this is not the case. Although features may
> be
> added or removed, trunk is usually the basis for whatever branch is made
> for
> the "next scala release" (i.e. 2.8, 2.9).

I strongly argue for 1). Trunk is not directionless, but it may not move
towards a set release target for much of the time. I will make a concrete
example. Some time before the actual release of 2.8.0, trunk was branched
to the 2.8.x branch. For some time following the fork, new features were
added to trunk as well as bug fixes. During this time the upcoming 2.8.0
codebase was stabilised, and only critical fixes were ported from trunk;
at the time, we assumed the new features would end up in a future 2.8.1.
Eventually, 2.8.x became quite stable, and 2.8.0 final released. After
much new development in trunk, we observed that the new features would end
up compromising binary compatibility. Therefore, we selectively ported
from trunk to 2.8.x the fixes that would not affect that compatibility,
and we are now preparing for 2.8.1. We plan to do the same for a future
2.8.2. Although it is true that at this time trunk should evolve towards
2.9, the target may well become 3.0, or something different. We can't say
what the target is until the 2.9.x branch is actually spawned. At that
time only will the codebase that evolves towards 2.9 be known. In short,
trunk keeps progressing over time across versions, while multiple target
versions evolve. Consequently I strongly argue that we should reserve the
identifiers 2.8-snapshot and 2.9-snapshot for the branches that concretely
evolve towards known versions, leaving trunk to follow its own path. I am
not sure it is of any use to call trunk "2.n" at any given time, knowing
that compatibility will keep being invalidated all the time, and also
knowing that the target may change. It's just a hassle, and will not
decrease confusion.

As an added argument, assuming we also release snapshots from 2.8.x, we
would end up with "2.8.1-SNAPSHOT" and "2.8.9999-SNAPSHOT" at the same
time. Besides being confusing, that is also wrong, since trunk is now
quite different from 2.8.x (and will probably also be different from any
2.9.x).

Personally I'd suggest the use of "2.8-SNAPSHOT" for 2.8.x releases, and
"0.0-SNAPSHOT" or similar for trunk. If three numbers are needed, I'd call
"2.8.9999-SNAPSHOT" the 2.8.x releases, and "0.0.0-SNAPSHOT" the releases
from trunk. That would at least maintain a unique release number during
the entire life of the 2.8.x branch. Further, it would remove the
confusion that arises from calling trunk "2.xx".

Toni

On Thu, Sep 9, 2010 at 9:37 PM, Antonio Cunei wrote:
> Personally I'd suggest the use of "2.8-SNAPSHOT" for 2.8.x releases, and
> "0.0-SNAPSHOT" or similar for trunk. If three numbers are needed, I'd call
> "2.8.9999-SNAPSHOT" the 2.8.x releases, and "0.0.0-SNAPSHOT" the releases
> from trunk. That would at least maintain a unique release number during
> the entire life of the 2.8.x branch. Further, it would remove the
> confusion that arises from calling trunk "2.xx".

This would be fine as a private versioning scheme, but I'm afraid it's
simply technically incompatible with the version schemes using by
Maven, Sbt and OSGi. If you go down this route you will be making life
extremely difficult for a very large proportion of Scala's users,
quite possibly the majority.

In the immediate short term, many projects, not just the Scala IDE
will be want to test their build infrastructure against the upcoming
2.8.1 release. For that to be possible we need to have Maven builds of
the current state of the 2.8.x branch pushed out to scala-tools.org.
The only sensible version number for those builds would be
2.8.1-SNAPSHOT. Currently that's not possible because that version
number is already occupied by trunk.

What we need now are builds of the 2.8.x branch labelled as
2.8.1-SNAPSHOT, and trunk builds correctly labelled with some version
number, I don't care what, so long as it's greater than 2.8.1. If I
have to, I'll do it myself, but really this is something that EPFL and
scala-tools.org should be sorting out.

Cheers,

Miles

On Thu, September 9, 2010 11:10 pm, Miles Sabin wrote:
> On Thu, Sep 9, 2010 at 9:37 PM, Antonio Cunei
> wrote:
>> Personally I'd suggest the use of "2.8-SNAPSHOT" for 2.8.x releases, and
>> "0.0-SNAPSHOT" or similar for trunk. If three numbers are needed, I'd
>> call
>> "2.8.9999-SNAPSHOT" the 2.8.x releases, and "0.0.0-SNAPSHOT" the
>> releases
>> from trunk. That would at least maintain a unique release number during
>> the entire life of the 2.8.x branch. Further, it would remove the
>> confusion that arises from calling trunk "2.xx".
>
> This would be fine as a private versioning scheme, but I'm afraid it's
> simply technically incompatible with the version schemes using by
> Maven, Sbt and OSGi.

As I mentioned several times, I do not know what kind of restriction the
Maven toolchain imposes, therefore I can only make suggestions here. If
they are not viable, we'll find a different way.

> What we need now are builds of the 2.8.x branch labelled as
> 2.8.1-SNAPSHOT, and trunk builds correctly labelled with some version
> number, I don't care what, so long as it's greater than 2.8.1. If I
> have to, I'll do it myself, but really this is something that EPFL and
> scala-tools.org should be sorting out.
>

I like the concept of "don't care what" for trunk. Could it be kept at
"9.9.9", in that case? Anything that keeps trunk well distinct from
upcoming release version numbers will do.

Concerning pushing 2.8.x snapshots, as you said I can't do that if trunk
is not out of the way, and I can't change the version number in trunk
until I am told by you (Miles and/or Josh, or other Maven users with
opinions on the matter) which is the name by which you want trunk
snapshots to be pushed out from now on. I can push trunk out as "0.0.0",
or "9.9.9" or anything else, as long as it doesn't change again, and there
is no potential for confusion with upcoming releases (I explained the
reasons in my previous message).

I will wait for feedback from scala-tools (Josh in this case) on their
preferred naming choice, then I'll change version numbers in trunk and
I'll start pushing 2.8.x as 2.8.1-snapshot, as discussed.
Toni

Responses inline

On Thu, Sep 9, 2010 at 4:37 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

On Thu, September 9, 2010 5:25 pm, Josh Suereth wrote:
>
> 1)  Calling trunk version 0.0.0  and modifying the tools to support this.
>  I"m not sure that SBT would have to change at all, but I know the
> maven-scala-plugin would.   I can make the changes to the
> maven-scala-pluign
> if/when this occurs.
> 2)  Calling trunk 2.8.999.   This would require no changes (temporarily)
> to
> any tools AFAICT but seems a poor long-term choice.
>
<snip/>

I strongly argue for 1). Trunk is not directionless, but it may not move
towards a set release target for much of the time. I will make a concrete
example. Some time before the actual release of 2.8.0, trunk was branched
to the 2.8.x branch. For some time following the fork, new features were
added to trunk as well as bug fixes. During this time the upcoming 2.8.0
codebase was stabilised, and only critical fixes were ported from trunk;
at the time, we assumed the new features would end up in a future 2.8.1.

<comment>

At the point when the 2.8.x branch was made, it would have been reasonable to up the version in trunk to 2.9 and port critical fixes to 2.8.1.    At the time, the theory that new features would make it into 2.8.1 would have been ok, except that the versioning scheme was determined it should mean something.   The last verison number apparently mandates binary compatibility now, and as such I think all x.x.Z releases should come from a x.x branch.   However, it's your call as to process.  I'm just suggesting what I've seen over many other places.

</comment>

Eventually, 2.8.x became quite stable, and 2.8.0 final released. After
much new development in trunk, we observed that the new features would end
up compromising binary compatibility. Therefore, we selectively ported
from trunk to 2.8.x the fixes that would not affect that compatibility,
and we are now preparing for 2.8.1. We plan to do the same for a future
2.8.2. Although it is true that at this time trunk should evolve towards
2.9, the target may well become 3.0, or something different.

<comment>

Changing from 2.9.0-SNAPSHOT to 3.0.0-SNAPSHOT would be alright IMHO.   Remember that it's more important that any SNAPSHOT is > the previous release. (where previous refers to a reasonable major.minor.bugfix version scheme.
 </comment>

We can't say
what the target is until the 2.9.x branch is actually spawned. At that
time only will the codebase that evolves towards 2.9 be known. In short,
trunk keeps progressing over time across versions, while multiple target
versions evolve. Consequently I strongly argue that we should reserve the
identifiers 2.8-snapshot and 2.9-snapshot for the branches that concretely
evolve towards known versions, leaving trunk to follow its own path. I am
not sure it is of any use to call trunk "2.n" at any given time, knowing
that compatibility will keep being invalidated all the time, and also
knowing that the target may change. It's just a hassle, and will not
decrease confusion.

<comment>

People are accustomed to having SNAPSHOTS change or have accidentally broken changes in them.  That's why it's called the bleeding edge.   Also, it's important to note that the snapshot versions include *all three* version numbers.  Therefore there is no 2.8-SNAPSHOT but a 2.8.0-SNAPSHOT.   The SNAPSHOT releases are supposed to be leading up to a release where the SNAPSHOT is dropped.  However moving forward a revision is fine.  Also reverting a change that is not ok is also fine in bleeding edge.   This happens all the time.   I still think it's reasonable to choose a target for trunk and retain the ability to change your mind later.   As long as you don't suddenly decide the next version of scala will be 2.7.9, I think we're ok here.

</comment>

As an added argument, assuming we also release snapshots from 2.8.x, we
would end up with "2.8.1-SNAPSHOT" and "2.8.9999-SNAPSHOT" at the same
time. Besides being confusing, that is also wrong, since trunk is now
quite different from 2.8.x (and will probably also be different from any
2.9.x).

<comment>
 I personally find 2.8.999-SNAPSHOT a horrible idea, mostly because trunk will never be binary compatible with 2.8.x and the x => binary compatibility, so choosing that version seems like a lie, but I'm willing to go with a community vote here.

Saying that trunk will not lead to a 2.9.x branch seems somewhat ridiculuous at this point.  Even if 2.9 gets changed to 3.0, some of the changes in trunk will eventually make it to 2.9 and some will not.   To imply that because some may be moved "further in the future" we shouldn't choose a sensible version seems ridiculous to me.   My software may have bugs, so I might as well write poor code.  (Sorry if this sounds derogatory, I'm slightly frustrated).
</comment>
 

Personally I'd suggest the use of "2.8-SNAPSHOT" for 2.8.x releases, and
"0.0-SNAPSHOT" or similar for trunk. If three numbers are needed, I'd call
"2.8.9999-SNAPSHOT" the 2.8.x releases, and "0.0.0-SNAPSHOT" the releases
from trunk. That would at least maintain a unique release number during
the entire life of the 2.8.x branch. Further, it would remove the
confusion that arises from calling trunk "2.xx".

<comment>
Ok, so why is it not possible to figure out what the third number will be for 2.8.x-SNAPSHOT?   I thought it was pretty standard for the Scala team to release these bug-fix releases in incremental versions.   Once again, deciding to skip a version later in the release cycle is fine and even has precedence.   Spring jumped to 2.5.   I don't really think assigning a goal for trunk is amazingly confusing and I'm not buying the arguments.   I think all the problems you mention are standard in a lot of shops dealing with distributed development.   I personally feel a refusal to assign any number to trunk is a refusal to abide by at least a minimal set of process.   I definitely enjoyed meeting the Scala team and I have a lot of respect for software development abilities each and every one of you that I met, but I think the release process could use some work.   I still think this lack of a decision on a target release for trunk is a large red flag.   What is acceptible to commit in trunk?   Can anyone dump whatever they want in?   How large a "fix" or 'enhancment' should I choose to bite off and throw in trunk?   Should my experimental feature be located on a branch?   These are all questions that have come up before on the mailing list and all of these could be solved with a minimal amount of process/rigor around the versioning + branching schemes in EPFL.    Right now the branch-for-release scheme is great.  I'd recommend following that up with the "trunk is for next feature release" practice.

In any case, Now that we've had some comments, my preference would be to call trunk 2.9.0-SNAPSHOT until such a time as a 2.9.x branch exists or the goal for trunk becomes something else (3.0 or even 4.0!).   However, in lieu of that, then I'd rather have the 2.x-branches in subversion use a legit SNAPSHOT version scheme and have trunk use 0.0.0.  

- Josh

On Thu, Sep 9, 2010 at 11:17 PM, Antonio Cunei wrote:
> I like the concept of "don't care what" for trunk. Could it be kept at
> "9.9.9", in that case? Anything that keeps trunk well distinct from
> upcoming release version numbers will do.

That would solve the short term problem for me. Josh? Mark? Are there
any practical objections to this?

Cheers,

Miles

How bout we push it to 9.9.9 for now.   All existing tools should work "ok" with this in the near-term future.  If you want I can make the commit as well.

- Josh

On Thu, Sep 9, 2010 at 6:17 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

On Thu, September 9, 2010 11:10 pm, Miles Sabin wrote:
> On Thu, Sep 9, 2010 at 9:37 PM, Antonio Cunei <antonio.cunei@epfl.ch>
> wrote:
>> Personally I'd suggest the use of "2.8-SNAPSHOT" for 2.8.x releases, and
>> "0.0-SNAPSHOT" or similar for trunk. If three numbers are needed, I'd
>> call
>> "2.8.9999-SNAPSHOT" the 2.8.x releases, and "0.0.0-SNAPSHOT" the
>> releases
>> from trunk. That would at least maintain a unique release number during
>> the entire life of the 2.8.x branch. Further, it would remove the
>> confusion that arises from calling trunk "2.xx".
>
> This would be fine as a private versioning scheme, but I'm afraid it's
> simply technically incompatible with the version schemes using by
> Maven, Sbt and OSGi.

As I mentioned several times, I do not know what kind of restriction the
Maven toolchain imposes, therefore I can only make suggestions here. If
they are not viable, we'll find a different way.

> What we need now are builds of the 2.8.x branch labelled as
> 2.8.1-SNAPSHOT, and trunk builds correctly labelled with some version
> number, I don't care what, so long as it's greater than 2.8.1. If I
> have to, I'll do it myself, but really this is something that EPFL and
> scala-tools.org should be sorting out.
>

I like the concept of "don't care what" for trunk. Could it be kept at
"9.9.9", in that case? Anything that keeps trunk well distinct from
upcoming release version numbers will do.

Concerning pushing 2.8.x snapshots, as you said I can't do that if trunk
is not out of the way, and I can't change the version number in trunk
until I am told by you (Miles and/or Josh, or other Maven users with
opinions on the matter) which is the name by which you want trunk
snapshots to be pushed out from now on. I can push trunk out as "0.0.0",
or "9.9.9" or anything else, as long as it doesn't change again, and there
is no potential for confusion with upcoming releases (I explained the
reasons in my previous message).

I will wait for feedback from scala-tools (Josh in this case) on their
preferred naming choice, then I'll change version numbers in trunk and
I'll start pushing 2.8.x as 2.8.1-snapshot, as discussed.
Toni

None from me for 9.9.9 as a "not long-term" fix

On Thu, Sep 9, 2010 at 6:26 PM, Miles Sabin <miles@milessabin.com> wrote:

On Thu, Sep 9, 2010 at 11:17 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:
> I like the concept of "don't care what" for trunk. Could it be kept at
> "9.9.9", in that case? Anything that keeps trunk well distinct from
> upcoming release version numbers will do.

That would solve the short term problem for me. Josh? Mark? Are there
any practical objections to this?

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

I hope you'll forgive me if I reply only to a section of your message; the
time is a bit late here, but I would like to address some of your concerns
nonetheless.

On Fri, September 10, 2010 12:27 am, Josh Suereth wrote:
> I don't really think assigning a
> goal
> for trunk is amazingly confusing and I'm not buying the arguments. I
> think
> all the problems you mention are standard in a lot of shops dealing with
> distributed development. I personally feel a refusal to assign any
> number
> to trunk is a refusal to abide by at least a minimal set of process. [...]
> I still think this lack
> of
> a decision on a target release for trunk is a large red flag. What is
> acceptible to commit in trunk? [..etc..]

Josh,

I think you're reading too much in the proposal to remove a version number
from trunk. As you know well, a set revision number is currently present
in trunk, and has always been. On occasion, as now, it is not up-to-date.
That is not a problem for day-to-day Scala development (other than with
Maven): the nightlies published on the Scala website have sometimes
inconsistent version numbers, but always contain the SVN revision number
and the build date, which is the information of relevance for non-Maven
users.

The matter is of course different for Maven; in that case the version
number in trunk is part of the information used by the build toolchain,
and unexpected behaviour will be encountered if that is not set to
whatever the user might expect. I am finding that out now, but since
no-one in the core team at EPFL uses Maven, that has never been brought to
our attention as a crucial aspect. That is the reason why the version
number written in the trunk source has been handled rather casually so
far. Conversely, it is always kept up-to-date in the release branches.

What I am trying to address here is the confusion that arises while
referring to snapshots coming from branches and trunk, as the title of
this email thread originally indicated. You should NOT mistake the fact
that I proposed to remove the version numbers from trunk as a lack of
planning or direction on our part! Of course at any time we are aiming for
a given future release! (even though the plan can change on occasion). The
code that ends in trunk is all due to be included in future releases, and
new features are only merged when they reach reasonable stability, of
course. It's disappointing that you would think otherwise.

The rationale for changing the version number in trunk to a neutral number
has nothing to do with the actual release plans, but only with
practicality, following recurring confusion by people who no longer know
which version number refers to what.

My thought, which may be incorrect due to my unfamiliarity with Maven,
went like the following: "So, we have this long list of nightly releases
on the Scala website. Now that we are going towards 2.8.1, the version
number in trunk has been changed, with the result that there are a bunch
of 2.8.0.rxxx releases and 2.8.1.rxxx releases, neither of which come from
2.8.x. This is wrong. We can publish nightlies from 2.8.x instead, but
then what should we call the releases from trunk? It may be 2.9.0.rxxx
now, but once we fork the actual 2.9.x branch this description will be
wrong again. Well, it may make sense to identify what comes from trunk
simply with a neutral marker, to avoid confusion". Nothing bad so far.
Now, Maven enters the picture. "I don't know how Maven works. However, it
seems reasonable to assume that people who want to follow snapshots may a)
want to follow progress leading to a future release, since their code has
to be adapted accordingly, or b) follow nightly trunk whatever that may
be, as they need the very latest fixes and features, regardless of
stability. This division fits nicely with what I had in mind. By assigning
an arbitrary version number to trunk, I can cater for people in group b,
while following the snapshots from the branches is what is needed by
people in group a. Let's see if the Maven guy are happy with this scheme".

What seems to have happened, as a result, is that you inferred that we
don't have any set plans for the development of our codebase. That is
entirely incorrect, and actually a bit insulting.

I should once again point out that we don't use Maven in the core team at
EPFL, so we can't know what fits the need of the Maven toolchain. I might
as well use an arbitrary identifier as the Scala build number in trunk,
and then push it to the repository with a different identifier/version
number in order to fulfill Maven's needs. I personally just run your
script, whatever that may contain: you are welcome to synthesise a
suitable version number in there while uploading, for example.

I hope the situation on my side is more clear, now. Version number in
trunk source = irrelevant for us, might as well be 0. Version number
planned for trunk development = important for everyone, currently 2.9.0.
Version number to be used to identify trunk in Maven = important for Maven
users, I don't particularly care. Just let me know what you prefer, or
adapt it yourself as needed.

Toni

On Thu, Sep 9, 2010 at 5:02 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

I hope you'll forgive me if I reply only to a section of your message; the
time is a bit late here, but I would like to address some of your concerns
nonetheless.

On Fri, September 10, 2010 12:27 am, Josh Suereth wrote:
> I don't really think assigning a
> goal
> for trunk is amazingly confusing and I'm not buying the arguments.   I
> think
> all the problems you mention are standard in a lot of shops dealing with
> distributed development.   I personally feel a refusal to assign any
> number
> to trunk is a refusal to abide by at least a minimal set of process. [...]
> I still think this lack
> of
> a decision on a target release for trunk is a large red flag.   What is
> acceptible to commit in trunk? [..etc..]

Josh,

I think you're reading too much in the proposal to remove a version number
from trunk. As you know well, a set revision number is currently present
in trunk, and has always been. On occasion, as now, it is not up-to-date.
That is not a problem for day-to-day Scala development (other than with
Maven): the nightlies published on the Scala website have sometimes
inconsistent version numbers, but always contain the SVN revision number
and the build date, which is the information of relevance for non-Maven
users.

The matter is of course different for Maven; in that case the version
number in trunk is part of the information used by the build toolchain,
and unexpected behaviour will be encountered if that is not set to
whatever the user might expect. I am finding that out now, but since
no-one in the core team at EPFL uses Maven, that has never been brought to
our attention as a crucial aspect. That is the reason why the version
number written in the trunk source has been handled rather casually so
far. Conversely, it is always kept up-to-date in the release branches.

What I am trying to address here is the confusion that arises while
referring to snapshots coming from branches and trunk, as the title of
this email thread originally indicated. You should NOT mistake the fact
that I proposed to remove the version numbers from trunk as a lack of
planning or direction on our part! Of course at any time we are aiming for
a given future release! (even though the plan can change on occasion). The
code that ends in trunk is all due to be included in future releases, and
new features are only merged when they reach reasonable stability, of
course. It's disappointing that you would think otherwise.

The rationale for changing the version number in trunk to a neutral number
has nothing to do with the actual release plans, but only with
practicality, following recurring confusion by people who no longer know
which version number refers to what.

My thought, which may be incorrect due to my unfamiliarity with Maven,
went like the following: "So, we have this long list of nightly releases
on the Scala website. Now that we are going towards 2.8.1, the version
number in trunk has been changed, with the result that there are a bunch
of 2.8.0.rxxx releases and 2.8.1.rxxx releases, neither of which come from
2.8.x. This is wrong. We can publish nightlies from 2.8.x instead, but
then what should we call the releases from trunk? It may be 2.9.0.rxxx
now, but once we fork the actual 2.9.x branch this description will be
wrong again. Well, it may make sense to identify what comes from trunk
simply with a neutral marker, to avoid confusion". Nothing bad so far.
Now, Maven enters the picture. "I don't know how Maven works. However, it
seems reasonable to assume that people who want to follow snapshots may a)
want to follow progress leading to a future release, since their code has
to be adapted accordingly, or b) follow nightly trunk whatever that may
be, as they need the very latest fixes and features, regardless of
stability. This division fits nicely with what I had in mind. By assigning
an arbitrary version number to trunk, I can cater for people in group b,
while following the snapshots from the branches is what is needed by
people in group a. Let's see if the Maven guy are happy with this scheme".

What seems to have happened, as a result, is that you inferred that we
don't have any set plans for the development of our codebase. That is
entirely incorrect, and actually a bit insulting.

I should once again point out that we don't use Maven in the core team at
EPFL, so we can't know what fits the need of the Maven toolchain. I might
as well use an arbitrary identifier as the Scala build number in trunk,
and then push it to the repository with a different identifier/version
number in order to fulfill Maven's needs. I personally just run your
script, whatever that may contain: you are welcome to synthesise a
suitable version number in there while uploading, for example.

I hope the situation on my side is more clear, now. Version number in
trunk source = irrelevant for us, might as well be 0. Version number
planned for trunk development = important for everyone, currently 2.9.0.
Version number to be used to identify trunk in Maven = important for Maven
users, I don't particularly care. Just let me know what you prefer, or
adapt it yourself as needed.

Toni

Toni,
Just to jump in... it's not a Maven issue, it's an issue related to any dependency-based build system.  That means Maven, Ant/Ivy and SBT.  Basically, the issue being discussed here impacts every single project that I've been involved in related to Scala over the last 3+ years.  So, I think that EPFL is in the radical minority in the Scala ecosystem (maybe ScalaTest is there as well) in terms of being a project with manual dependency resolution.
There is plenty of requirements, help and guidance coming from folks in the community.  The pain that bad decisions causes is tremendous.  While EPFL may not feel the pain, virtually everybody in the Scala community that is using nightlies will feel the pain.
I hope that this helps describe the importance of the situation.
Thanks,
David 


--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

Tony, I did not mean to be insulting or demeaning, rather it seems a lack of understanding on both our parts.  

One thing I'd like to mention is that this version scheme affect maven *repositories* which is not just maven.   It will actually affect SBT users (which are a subset of), Ivy users and Maven users equally.  In fact, I think Gradle may even use our repo for scala builds.

Now, for a bit of a final response.   Maven has automated ways to do this, but it is customary when cutting a branch for a release to make the branch against trunk and immediately follow it up with a commit to trunk that bumps to target version number of trunk.   In maven this can be automated via the release plugin (as davidB does for the maven-scala-plugin).  For Scala it seems this has to be a manual process.   I was not aware that no one at EPFL used the maven artifacts as I thought some folks were using SBT for buiilds (but I guess they were using the "local" option.  

In any case, if trunk is target at 2.9, then I think the version in trunk should be 2.9.0, and the nightly 2.9.0-SNAPSHOT.   When a 2.9-branch occurs, then the version in trunk should be bumped *or* the trunk nightly maven-deployments should cease (let me know if this is something I should do.   I am more than willing to be the 'release bumper').

This would meet the expectations of the maven repository users (sbt, ivy + maven).

As a side note, having a 9.9.9-SNAPSHOT version in the repository which means "trunk" would be something never-before-seen in the maven world.   This is not necessarily bad, but perhaps unexpected and confusing.

Sorry for the confusion,   and sorry for keeping you up late!   I know you guys are doing your best, hopefully this helps shed some light on the standards of maven repository usage.

- Josh

On Thu, Sep 9, 2010 at 8:02 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

I hope you'll forgive me if I reply only to a section of your message; the
time is a bit late here, but I would like to address some of your concerns
nonetheless.

On Fri, September 10, 2010 12:27 am, Josh Suereth wrote:
> I don't really think assigning a
> goal
> for trunk is amazingly confusing and I'm not buying the arguments.   I
> think
> all the problems you mention are standard in a lot of shops dealing with
> distributed development.   I personally feel a refusal to assign any
> number
> to trunk is a refusal to abide by at least a minimal set of process. [...]
> I still think this lack
> of
> a decision on a target release for trunk is a large red flag.   What is
> acceptible to commit in trunk? [..etc..]

Josh,

I think you're reading too much in the proposal to remove a version number
from trunk. As you know well, a set revision number is currently present
in trunk, and has always been. On occasion, as now, it is not up-to-date.
That is not a problem for day-to-day Scala development (other than with
Maven): the nightlies published on the Scala website have sometimes
inconsistent version numbers, but always contain the SVN revision number
and the build date, which is the information of relevance for non-Maven
users.

The matter is of course different for Maven; in that case the version
number in trunk is part of the information used by the build toolchain,
and unexpected behaviour will be encountered if that is not set to
whatever the user might expect. I am finding that out now, but since
no-one in the core team at EPFL uses Maven, that has never been brought to
our attention as a crucial aspect. That is the reason why the version
number written in the trunk source has been handled rather casually so
far. Conversely, it is always kept up-to-date in the release branches.

What I am trying to address here is the confusion that arises while
referring to snapshots coming from branches and trunk, as the title of
this email thread originally indicated. You should NOT mistake the fact
that I proposed to remove the version numbers from trunk as a lack of
planning or direction on our part! Of course at any time we are aiming for
a given future release! (even though the plan can change on occasion). The
code that ends in trunk is all due to be included in future releases, and
new features are only merged when they reach reasonable stability, of
course. It's disappointing that you would think otherwise.

The rationale for changing the version number in trunk to a neutral number
has nothing to do with the actual release plans, but only with
practicality, following recurring confusion by people who no longer know
which version number refers to what.

My thought, which may be incorrect due to my unfamiliarity with Maven,
went like the following: "So, we have this long list of nightly releases
on the Scala website. Now that we are going towards 2.8.1, the version
number in trunk has been changed, with the result that there are a bunch
of 2.8.0.rxxx releases and 2.8.1.rxxx releases, neither of which come from
2.8.x. This is wrong. We can publish nightlies from 2.8.x instead, but
then what should we call the releases from trunk? It may be 2.9.0.rxxx
now, but once we fork the actual 2.9.x branch this description will be
wrong again. Well, it may make sense to identify what comes from trunk
simply with a neutral marker, to avoid confusion". Nothing bad so far.
Now, Maven enters the picture. "I don't know how Maven works. However, it
seems reasonable to assume that people who want to follow snapshots may a)
want to follow progress leading to a future release, since their code has
to be adapted accordingly, or b) follow nightly trunk whatever that may
be, as they need the very latest fixes and features, regardless of
stability. This division fits nicely with what I had in mind. By assigning
an arbitrary version number to trunk, I can cater for people in group b,
while following the snapshots from the branches is what is needed by
people in group a. Let's see if the Maven guy are happy with this scheme".

What seems to have happened, as a result, is that you inferred that we
don't have any set plans for the development of our codebase. That is
entirely incorrect, and actually a bit insulting.

I should once again point out that we don't use Maven in the core team at
EPFL, so we can't know what fits the need of the Maven toolchain. I might
as well use an arbitrary identifier as the Scala build number in trunk,
and then push it to the repository with a different identifier/version
number in order to fulfill Maven's needs. I personally just run your
script, whatever that may contain: you are welcome to synthesise a
suitable version number in there while uploading, for example.

I hope the situation on my side is more clear, now. Version number in
trunk source = irrelevant for us, might as well be 0. Version number
planned for trunk development = important for everyone, currently 2.9.0.
Version number to be used to identify trunk in Maven = important for Maven
users, I don't particularly care. Just let me know what you prefer, or
adapt it yourself as needed.

Toni

On Fri, September 10, 2010 2:10 am, David Pollak wrote:
> Just to jump in... it's not a Maven issue, it's an issue related to any
> dependency-based build system. That means Maven, Ant/Ivy and SBT.
> Basically, the issue being discussed here impacts every single project
> that
> I've been involved in related to Scala over the last 3+ years. So, I
> think
> that EPFL is in the radical minority in the Scala ecosystem (maybe
> ScalaTest
> is there as well) in terms of being a project with manual dependency
> resolution.
>
> There is plenty of requirements, help and guidance coming from folks in
> the
> community. The pain that bad decisions causes is tremendous. While EPFL
> may not feel the pain, virtually everybody in the Scala community that is
> using nightlies will feel the pain.
>

David,

As this discussion proves, there is a constant exchange between EPFL and
the user base. We do not take decisions unilaterally, and no process
changes have been made so far by us, for the very reason that the matter
is still being discussed.

As I specified, the version number stored in the trunk source is
irrelevant for us, since we do not rely on automated dependency
management. If the community has specific needs concerning this aspect, we
are eager to know; this entire thread has this purpose.

Thankfully, the last email from Josh does exactly that, and contains a
simple explanation of requirements; I'll be happy to comply. So, no need
to worry.

Toni

On Fri, September 10, 2010 2:18 am, Josh Suereth wrote:
> Now, for a bit of a final response. Maven has automated ways to do this,
> but it is customary when cutting a branch for a release to make the branch
> against trunk and immediately follow it up with a commit to trunk that
> bumps
> to target version number of trunk. In maven this can be automated via
> the
> release plugin (as davidB does for the maven-scala-plugin). For Scala it
> seems this has to be a manual process. I was not aware that no one at
> EPFL
> used the maven artifacts as I thought some folks were using SBT for
> buiilds
> (but I guess they were using the "local" option.
>
> In any case, if trunk is target at 2.9, then I think the version in trunk
> should be 2.9.0, and the nightly 2.9.0-SNAPSHOT. When a 2.9-branch
> occurs,
> then the version in trunk should be bumped *or* the trunk nightly
> maven-deployments should cease (let me know if this is something I should
> do. I am more than willing to be the 'release bumper').
>
> This would meet the expectations of the maven repository users (sbt, ivy +
> maven).
>

Thanks for your explanation, Josh. Indeed, as I mentioned, the version
number in trunk has always been dealt with manually, and at times a bit
casually, since no-one here was relying on that bit of information.
Knowing that it is instead of the essence for Maven and associated tools
changes the matter quite a bit.

Your description is clear, and the requirements simple; I'll take care of
applying the necessary changes the next time we spawn a new 2.x.x branch.

A similar aspect, I suppose, will therefore concern the version number in
the branches. For instance, let's say there is a release of 2.8.1 at some
point. Because of reasons similar to trunk, the version number was never
updated immediately afterwards, but rather only at some random point
before the following RC, in this case probably shortly before 2.8.2.RC1.

By analogy, I suppose you will also need instead the version number to be
bumped in the branch immediately after each final from the branch.
Correct? In that case, is it also ok for you to bump version number
immediately in the branch even if there may not be any further release
from the branch, or would the additional spurious snapshots cause problems
in the repository?

Toni

On Thu, Sep 9, 2010 at 8:47 PM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:

<snip/>

Thanks for your explanation, Josh. Indeed, as I mentioned, the version
number in trunk has always been dealt with manually, and at times a bit
casually, since no-one here was relying on that bit of information.
Knowing that it is instead of the essence for Maven and associated tools
changes the matter quite a bit.

Your description is clear, and the requirements simple; I'll take care of
applying the necessary changes the next time we spawn a new 2.x.x branch.

Great!  I'm glad we've reached an understanding here!  Hopefully, I'll do a better job elucidating the requirements next time.
 

A similar aspect, I suppose, will therefore concern the version number in
the branches. For instance, let's say there is a release of 2.8.1 at some
point. Because of reasons similar to trunk, the version number was never
updated immediately afterwards, but rather only at some random point
before the following RC, in this case probably shortly before 2.8.2.RC1.

By analogy, I suppose you will also need instead the version number to be
bumped in the branch immediately after each final from the branch.
Correct? In that case, is it also ok for you to bump version number
immediately in the branch even if there may not be any further release
from the branch, or would the additional spurious snapshots cause problems
in the repository?

Yes.  This is exactly what we'd love to see.   Having a 2.8.3-SNAPSHOT with no foreseeable release is ok.   Users who want bug fixes on 2.8.2 will most likely move to 2.9 in the near future.  In practice, if someone needs a 2.8.3-SNAPSHOT, I've (personally) created my own "2.8.3-mycompany" release including what fixes I needed from that branch as a stop-gap until either 2.8.3 did get released or some 2.9.x was released and the project had time to migrate.    Regardless of what users do, this is a perfectly reasonable scenario and has precedence in other projects.


Thanks so much!

- Josh

On Fri, September 10, 2010 3:01 am, Josh Suereth wrote:
> Yes. This is exactly what we'd love to see. Having a 2.8.3-SNAPSHOT
> with
> no foreseeable release is ok. Users who want bug fixes on 2.8.2 will
> most
> likely move to 2.9 in the near future. In practice, if someone needs a
> 2.8.3-SNAPSHOT, I've (personally) created my own "2.8.3-mycompany" release
> including what fixes I needed from that branch as a stop-gap until either
> 2.8.3 did get released or some 2.9.x was released and the project had time
> to migrate. Regardless of what users do, this is a perfectly reasonable
> scenario and has precedence in other projects.
>
> Thanks so much!
>

No problems! I will bump trunk to 2.9.0 and activate 2.8.1 snapshots (from
the 2.8.x branch) during the weekend.

Toni

One last suggestion, which is probably obvious to all: let's ensure
that the version numbers of the nightlies published on scala-lang [1]
are consistent (modulo the -SNAPSHOT suffix) with those on
scala-tools.

Thanks to Toni and Josh for nutting out the issues! Small changes like
this can help to reduce the barrier for feedback on the freshly baked
bits.

-jason

[1] http://www.scala-lang.org/node/212/distributions

On Fri, Sep 10, 2010 at 3:17 AM, Antonio Cunei wrote:
> No problems! I will bump trunk to 2.9.0 and activate 2.8.1 snapshots (from
> the 2.8.x branch) during the weekend.

On Fri, Sep 10, 2010 at 2:17 AM, Antonio Cunei wrote:
> No problems! I will bump trunk to 2.9.0 and activate 2.8.1 snapshots (from
> the 2.8.x branch) during the weekend.

That's fantastic! Many thanks Toni ...

Cheers,

Miles

I changed the 2.8.x nightly build to publish the artifacts.Lukas

On Fri, Sep 10, 2010 at 08:29, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Sep 10, 2010 at 2:17 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:
> No problems! I will bump trunk to 2.9.0 and activate 2.8.1 snapshots (from
> the 2.8.x branch) during the weekend.

That's fantastic! Many thanks Toni ...

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Thanks Lukas!

On Fri, Sep 10, 2010 at 9:58 AM, Lukas Rytz <lukas.rytz@epfl.ch> wrote:

I changed the 2.8.x nightly build to publish the artifacts.Lukas

On Fri, Sep 10, 2010 at 08:29, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Sep 10, 2010 at 2:17 AM, Antonio Cunei <antonio.cunei@epfl.ch> wrote:
> No problems! I will bump trunk to 2.9.0 and activate 2.8.1 snapshots (from
> the 2.8.x branch) during the weekend.

That's fantastic! Many thanks Toni ...

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Thanks Toni and Lukas ...

Quick sanity check though ... are the 2.8.x branch nightlies being
pushed to scala-tools.org? Looking here,

http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/2.8....

the most recent build is from the 12th ... was there a problem with
the 2.8.x builds on the 13th and 14th?

Cheers,

Miles

On Fri, Sep 10, 2010 at 2:58 PM, Lukas Rytz wrote:
> I changed the 2.8.x nightly build to publish the artifacts.
> Lukas
>
> On Fri, Sep 10, 2010 at 08:29, Miles Sabin wrote:
>>
>> On Fri, Sep 10, 2010 at 2:17 AM, Antonio Cunei
>> wrote:
>> > No problems! I will bump trunk to 2.9.0 and activate 2.8.1 snapshots
>> > (from
>> > the 2.8.x branch) during the weekend.
>>
>> That's fantastic! Many thanks Toni ...
>>
>> Cheers,
>>
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel: +44 7813 944 528
>> gtalk: miles@milessabin.com
>> skype: milessabin
>> http://www.chuusai.com/
>> http://twitter.com/milessabin
>
>

On Wed, September 15, 2010 12:06 am, Miles Sabin wrote:
> Thanks Toni and Lukas ...
>
> Quick sanity check though ... are the 2.8.x branch nightlies being
> pushed to scala-tools.org? Looking here,
>
> http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/2.8....
>
> the most recent build is from the 12th ... was there a problem with
> the 2.8.x builds on the 13th and 14th?
>

You show little faith :) There is a new nightly from tonight,
2.8.1-20100915.013338-11.

On the 13th there were no changes, so no new nightly was published; on the
14th I had started a build manually as a test, which inhibited the
following nightly. All is under control.

This release will be an RC1: we will wait for feedback for a minimum of
two weeks in any case before a final, in any case. There will be further
time for testing and additional fixes, therefore.

Toni

On Wed, Sep 15, 2010 at 07:30:51AM +0200, Antonio Cunei wrote:
> You show little faith :) There is a new nightly from tonight,
> 2.8.1-20100915.013338-11.

I think you mean "I find your lack of faith disturbing."

Don't try to frighten us with your sorcerous ways, Lord Cunei!

On Wed, Sep 15, 2010 at 6:30 AM, Antonio Cunei wrote:
> On Wed, September 15, 2010 12:06 am, Miles Sabin wrote:
>> Thanks Toni and Lukas ...
>>
>> Quick sanity check though ... are the 2.8.x branch nightlies being
>> pushed to scala-tools.org? Looking here,
>>
>>   http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/2.8....
>>
>> the most recent build is from the 12th ... was there a problem with
>> the 2.8.x builds on the 13th and 14th?
>>
>
> You show little faith :) There is a new nightly from tonight,
> 2.8.1-20100915.013338-11.
>
> On the 13th there were no changes, so no new nightly was published; on the
> 14th I had started a build manually as a test, which inhibited the
> following nightly. All is under control.
>
> This release will be an RC1: we will wait for feedback for a minimum of
> two weeks in any case before a final, in any case. There will be further
> time for testing and additional fixes, therefore.

Thanks Toni :-)

Cheers,

Miles

Surely you mean:
Antonio: [Making a small pass with his hand] These aren't the builds you are looking forScala Users: These aren't the builds we are looking for...


On 15 September 2010 06:47, Paul Phillips <paulp@improving.org> wrote:

On Wed, Sep 15, 2010 at 07:30:51AM +0200, Antonio Cunei wrote:
> You show little faith :) There is a new nightly from tonight,
> 2.8.1-20100915.013338-11.

I think you mean "I find your lack of faith disturbing."

Don't try to frighten us with your sorcerous ways, Lord Cunei!

--
Paul Phillips      | Every normal man must be tempted at times
Caged Spirit       | to spit on his hands, hoist the black flag,
Empiricist         | and begin to slit throats.
i pull his palp!   |     -- H. L. Mencken

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

:)

I will try this trick, the next time the build is broken...
Toni

Kevin Wright wrote:
> Surely you mean:
>
> *Antonio*: [Making a small pass with his hand] These aren't the builds you
> are looking for
> *Scala Users*: These aren't the builds we are looking for...
>
>
>
> On 15 September 2010 06:47, Paul Phillips wrote:
>
>> On Wed, Sep 15, 2010 at 07:30:51AM +0200, Antonio Cunei wrote:
>>> You show little faith :) There is a new nightly from tonight,
>>> 2.8.1-20100915.013338-11.
>> I think you mean "I find your lack of faith disturbing."
>>
>> Don't try to frighten us with your sorcerous ways, Lord Cunei!
>>
>> --
>> Paul Phillips | Every normal man must be tempted at times
>> Caged Spirit | to spit on his hands, hoist the black flag,
>> Empiricist | and begin to slit throats.
>> i pull his palp! | -- H. L. Mencken
>>
>
>
>

Isn't it "sorceror's ways"?

> Date: Tue, 14 Sep 2010 22:47:08 -0700
> From: paulp@improving.org
>
> Don't try to frighten us with your sorcerous ways, Lord Cunei!