Scala 2.9.0.1

Hi Toni,

Thanks for this.

On Wed, May 25, 2011 at 4:17 PM, Antonio Cunei wrote:
> We are releasing a small update to the Scala 2.9.0 code.
> The new 2.9.0.1 hotfix release addresses a couple of issues
> found in 2.9.0, and is currently available from our Download

It seems like this was deployed as 2.9.0-1 in Maven for some reason:

http://scala-tools.org/repo-releases/org/scala-lang/scala-library/2.9.0-1/

Best,
Ismael

On 25/05/2011 17:49, Ismael Juma wrote:
> It seems like this was deployed as 2.9.0-1 in Maven for some reason:
>
> http://scala-tools.org/repo-releases/org/scala-lang/scala-library/2.9.0-1/
>

The standard for Maven version number does not allow a four-part version
number, and on the other hand 2.9.0.1 is supposed to be entirely
compatible with 2.9.0, bar for those fixes.

Therefore the artifacts were published on the Maven repository as
"2.9.0-1", where the final "1" takes the place of the build number. If
you selected "2.9.0" as a version number, this hotfix should be selected
automatically.

Or at least so I was told, I am no Maven expert :)
Toni

On Wed, May 25, 2011 at 4:55 PM, Antonio Cunei wrote:
> The standard for Maven version number does not allow a four-part version
> number, and on the other hand 2.9.0.1 is supposed to be entirely compatible
> with 2.9.0, bar for those fixes.

I see.

> Therefore the artifacts were published on the Maven repository as "2.9.0-1",
> where the final "1" takes the place of the build number. If you selected
> "2.9.0" as a version number, this hotfix should be selected automatically.

I wonder if other tools like SBT do the same. Personally, I think this
should have just been 2.9.1 instead of introducing the inconsistency.
Bug-fix releases are meant to be fully compatible anyway.

Best,
Ismael

I wonder if other tools like SBT do the same. Personally, I think this
should have just been 2.9.1 instead of introducing the inconsistency.
Bug-fix releases are meant to be fully compatible anyway.

SBT seems to go after the specific revision (rather than the latest *-n release), which suggests that other Ivy2-based tools (like Gradle) will do the same.  Not sure this is a particular problem, but I definitely would have preferred 2.9.1 instead of 2.9.0.

The bigger issue is that cross-build techniques (most notably, SBT) fall over in the face of this change.  So, regardless of what Maven is going to do with the -1 suffix, anything involving cross-building is going to need to be rebuild and redeployed anyway (since it works by an artifactId suffix, rather than a versioning trick).  In short, the whole suffix thing was very well-meaning, but I'm pretty sure that in practice, it's not going to make much of a difference.  Going with 2.9.1 would have been less confusing.

Daniel

On Wed, May 25, 2011 at 5:14 PM, Daniel Spiewak wrote:
> In short, the whole suffix thing was very
> well-meaning, but I'm pretty sure that in practice, it's not going to make
> much of a difference.  Going with 2.9.1 would have been less confusing.

Yes. We have already had someone asking if this release was stable or
unstable on IRC. It would be nice if these things were discussed
beforehand. Oh well.

Best,
Ismael

I just wonder why people have to break versioning all the time.

This is worse than "2.8 vs. 3.0", because that at least didn't break 80%
of the tooling around Scala.
All the breakage around that was foreseeable... why wasn't there some
testing?

Has Scala become such "enterprisey" that we have to save patch releases
to look more stable now?

*sigh*

/rant

Bye,

Simon

The "-1" part of the version number, is called the qualifier in the maven terminology and isn't intended at all to be used for subversioning.
This simply break compatibility with all existing maven tools exactly the same way IE did with HTML few years ago.

So it would be really better to change versioning strategy to reflect the one used by the whole java world instead of asking every maven impl to change.
I'm sure lot of Scala developer use SBT, it's just a shame that this update isn't compatible with it...
Personally I really prefer:0.1.00.1.1 <- backward compatible0.2.0 <- not b.c.
Cheers,
On 25 May 2011 18:31, Ismael Juma <ismael@juma.me.uk> wrote:

On Wed, May 25, 2011 at 5:14 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:
> In short, the whole suffix thing was very
> well-meaning, but I'm pretty sure that in practice, it's not going to make
> much of a difference.  Going with 2.9.1 would have been less confusing.

Yes. We have already had someone asking if this release was stable or
unstable on IRC. It would be nice if these things were discussed
beforehand. Oh well.

Best,
Ismael

--
Alois Cochardhttp://aloiscochard.blogspot.comhttp://twitter.com/aloiscochard

Judging from a popular realtime messaging service, everyone hates it:

"Oh dear. #Scala patch release is 2.9.0-1 instead of 2.9.1 ... is there
anything that that doesn't break?"

"Now Scala has inherited Java's tendency to invent a new versioning
system with each version: 2.9.0.1, WTF?"

"...and #Scala keeps reinventing versioning systems. Oh well, I am
having a bad day..."

Isn't it possible to just re-release it as 2.9.1 and forget about the
2.9.0.1 mess as fast as possible?

On 5/25/11 9:23 AM, Simon Ochsenreither wrote:
> I just wonder why people have to break versioning all the time.

Oh come on, the version number made perfect sense. This was such a
minor patch release that they did not think that it merited a full bump
in the third digit so they bumped the fourth digit instead. I may very
well have made the same decision in their place. Many tools don't place
restrictions on the exact number of digits on version numbers precisely
to allow developers the freedom to be flexible in their versioning so
that they can communicate more clearly exactly how much changed in the
latest release relative to other releases.

Having said that, to the extent that the Java community and tool
infrastructure have all standardized on three-digit versions, I do in
the end agree that probably Scala should stick with three-digit versions
in order to remain compatible with everything else, regardless of
whether this is the optimal versioning strategy. I just think that we
should not be so quick to jump on the developers for having been so
'obviously unreasonable'.

Cheers,
Greg

There's not much excuse for stepping outside of a very commonly used convention for version numbers understood by a lot of developer tooling for no perceivable benefit.  It creates unnecessary (and sadly boring) work.
However - this can be fixed by releasing the same artifacts as 2.9.1 with little pain can't it?
Cheers
Brian

On 25 May 2011 20:21, Gregory Crosswhite <gcrosswhite@gmail.com> wrote:

On 5/25/11 9:23 AM, Simon Ochsenreither wrote:

I just wonder why people have to break versioning all the time.

Oh come on, the version number made perfect sense.  This was such a minor patch release that they did not think that it merited a full bump in the third digit so they bumped the fourth digit instead.  I may very well have made the same decision in their place.  Many tools don't place restrictions on the exact number of digits on version numbers precisely to allow developers the freedom to be flexible in their versioning so that they can communicate more clearly exactly how much changed in the latest release relative to other releases.

Having said that, to the extent that the Java community and tool infrastructure have all standardized on three-digit versions, I do in the end agree that probably Scala should stick with three-digit versions in order to remain compatible with everything else, regardless of whether this is the optimal versioning strategy.  I just think that we should not be so quick to jump on the developers for having been so 'obviously unreasonable'.

Cheers,
Greg

Brian,

That is certainly a fair point.  My concern was mostly just the way that so many people were so quick to jump on the developers for being so obviously unreasonable rather than just explaining to them why they believed the solution was sub-optimal and politely requesting that they reconsider.

Probably the ideal situation would be for the community itself to come up with an official versioning policy in order to settle this matter once and for all.

Cheers,
Greg

On 5/25/11 12:31 PM, Brian Smith wrote:

X9p24M5BUmu4Q [at] mail [dot] gmail [dot] com" type="cite">There's not much excuse for stepping outside of a very commonly used convention for version numbers understood by a lot of developer tooling for no perceivable benefit.  It creates unnecessary (and sadly boring) work.
However - this can be fixed by releasing the same artifacts as 2.9.1 with little pain can't it?
Cheers
Brian

On 25 May 2011 20:21, Gregory Crosswhite <gcrosswhite [at] gmail [dot] com" rel="nofollow">gcrosswhite@gmail.com> wrote:

On 5/25/11 9:23 AM, Simon Ochsenreither wrote:

I just wonder why people have to break versioning all the time.

Oh come on, the version number made perfect sense.  This was such a minor patch release that they did not think that it merited a full bump in the third digit so they bumped the fourth digit instead.  I may very well have made the same decision in their place.  Many tools don't place restrictions on the exact number of digits on version numbers precisely to allow developers the freedom to be flexible in their versioning so that they can communicate more clearly exactly how much changed in the latest release relative to other releases.

Having said that, to the extent that the Java community and tool infrastructure have all standardized on three-digit versions, I do in the end agree that probably Scala should stick with three-digit versions in order to remain compatible with everything else, regardless of whether this is the optimal versioning strategy.  I just think that we should not be so quick to jump on the developers for having been so 'obviously unreasonable'.

Cheers,
Greg

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

Hope this clarifies things.

Best

 -- Martin

Just wondering what kind of software would depend on "2.9.0.1" vs "2.9.1"... I think these folks should look at the mirror.

On 5/25/11 12:46 PM, martin odersky wrote:
> For a language release, versioning is not as simple as it might appear
> to some folks. Here's the scheme we use, and will continue using.
>
> First digit: Major, backwards incompatible change such as going from
> Python 2 to Python 3.
>
> Second digit: Language stays source compatible. Libraries can do
> controlled breaking changes (usually accompanied by deprecation
> warnings). Binary compatibility is not guaranteed.
>
> Third digit: Bug-fix release, or add new functionality to language and
> libraries. Binary compatibility is preserved. These come every 3-6
> months, and they need RCs. They might contain 100 fixes or more, and
> might introduce new library packages or even smallish language additions.
>
> Fourth digit like the one we just issued: Maintenance release for a
> small number of critical fixes. No RCs.
>
> There's precedent for that: JDK releases also come with 4 digits.
>
> Hope this clarifies things.
>
> Best
>

Dear Martin,
Thanks for the explanation, I confess I didn't took the source compatibility vs binary compatibility into account.Now, I totally agree we can't use the same versioning strategy for a language as the one used for libraries; and the one you choose make sense.
We all see Scala as a language (since we are editing scala sources and using scala tools), a nice language that I'm really thankful you created.
BUT, In a JVM point of view Scala is nothing more than a library...
For sure we can adapt Scala tools like SBT to suit our specific needs, but that break the compatibility with every others Java tools. I'm sure Scala can have a huge impact in the enterprise world, but this imply being fully compatible with Maven which is by far the most used dependency manager.
Even if it's not such a big deal to add "-1", it's not compliant with the Maven syntax:http://sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
So, I think we need a strategy to convert "Scala Language Version" to "Scala Java Library Version".
As you say, first digit represent major, backward incompatible change. Such change imply huge impact in a project.
I propose to put the major digit in the artifactId, like that:artifactId = "scala-2"version = "9.0.1"
We can live with this "-1" trick, but if we find a solution to fix it, everybody will be happier :)
Cheers,
On 25 May 2011 21:46, martin odersky <martin.odersky@epfl.ch> wrote:

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

Hope this clarifies things.

Best

 -- Martin

--
Alois Cochardhttp://aloiscochard.blogspot.comhttp://twitter.com/aloiscochard

+1 for any scheme that preserves compatibility with Maven and existing
tooling. Maven is the current champ for build systems used in
enterprise Java software. Compatibility with its repository versioning
scheme should be important if the goal is to make Scala a widely
adopted enterprise language.

Alois's point is a good one. Scala could still use a 4 digit
versioning in all referenced literature, project pages, etc. A simple
mapping to an appropriate maven artifact/version to support *JVM*
based tooling is all that's required.

thanks for listening,
Adam

+1 to keep standard version: major.minor.fix

-1 that the third digit may introduce language additions. It will bring nothing but confusion.

-
Andrey

On 25 May 2011 20:46, martin odersky <martin.odersky@epfl.ch> wrote:

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

Hope this clarifies things.

Best

 -- Martin

One very crucial difference being that JDK releases don't come in the form of Maven artefacts, so the JDK team don't have to worry about tooling compatibility for version numbers in quite the same way.
Using build numbers looks to be valid Maven AFAICT, but it's also a little-known feature; so I have some concerns that it may not be well supported across other third party tools that interact with Maven.  


Much more concerning is the naming inconsistency though, this is being publicised as "2.9.0.1" yet we'll all be using it as "2.9.0-1" from maven, sbt, etc.  Assuming that there are no technical difficulties caused by the convention, can we not at least name the release "2.9.0-1" everywhere.  Including blogs, wiki entries, email subjects, etc. to avoid any possible confusion?
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On Wed, May 25, 2011 at 21:46, martin odersky <martin.odersky@epfl.ch> wrote:

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

True, but: the first digit didn't change in 16 years of Java. And the "public" versionnumbers got simplified over time, now they only have 2 digits: - 4 digits: 1.4.x_z  - 3 digits: J2SE 5.0 Update x - 2 digits: Java SE 6 Update x
(I am not saying we should introduce differing internal and public version numbers :)

On Thu, May 26, 2011 at 9:43 AM, Lukas Rytz wrote:
> True, but: the first digit didn't change in 16 years of Java. And the
> "public" version
> numbers got simplified over time, now they only have 2 digits:
>  - 4 digits: 1.4.x_z
>  - 3 digits: J2SE 5.0 Update x
>  - 2 digits: Java SE 6 Update x
> (I am not saying we should introduce differing internal and public version
> numbers :)

I was just writing this. :) One correction, the 2 digit scheme was
introduced in Java 5. That's why there was never a Java 5.1.

Also, having betas/RCs for some point releases and not others is
perfectly fine. JetBrains does this with IDEA _and_ Oracle does this
for Java (just 2 examples). For Java, some of the "update" releases
are minor fixes and security fixes and others include big changes like
a new HotSpot. In the latter case, they publish "early access"
releases.

A point release should always be fully compatible (source and binary)
so I don't see a strong need for a 4th digit.

Best,
Ismael

I love the fact that few seem to have considered the obvious: a build system that makes naming requirements of teams over which it has no control (and which may not use that system) is a build system with a problem. In fact, I might go as far as saying it is a fundamentally broken build system.
Chris

On Thu, May 26, 2011 at 9:24 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 25 May 2011 20:46, martin odersky <martin.odersky@epfl.ch> wrote:

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

Hope this clarifies things.

Best

 -- Martin

One very crucial difference being that JDK releases don't come in the form of Maven artefacts, so the JDK team don't have to worry about tooling compatibility for version numbers in quite the same way.
Using build numbers looks to be valid Maven AFAICT, but it's also a little-known feature; so I have some concerns that it may not be well supported across other third party tools that interact with Maven.  


Much more concerning is the naming inconsistency though, this is being publicised as "2.9.0.1" yet we'll all be using it as "2.9.0-1" from maven, sbt, etc.  Assuming that there are no technical difficulties caused by the convention, can we not at least name the release "2.9.0-1" everywhere.  Including blogs, wiki entries, email subjects, etc. to avoid any possible confusion?
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On Wednesday, May 25, 2011 1:22:55 PM UTC-4, Alois Cochard wrote:

The "-1" part of the version number, is called the qualifier in the maven terminology and isn't intended at all to be used for subversioning.

No. When numeric, it's called the build number and is very much used for versioning:
http://mojo.codehaus.org/versions-maven-plugin/version-rules.html
"2.9.0-1" therefore does not break Maven usage. Matter of fact, anyone who has a POM specifying 2.9.0 as the version will automatically update to 2.9.0-1 without human intervention after their next m2 index update -- that's desired behavior IMO.

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.
- Josh
On Thu, May 26, 2011 at 6:05 AM, Chris Marshall <oxbowlakes@gmail.com> wrote:

I love the fact that few seem to have considered the obvious: a build system that makes naming requirements of teams over which it has no control (and which may not use that system) is a build system with a problem. In fact, I might go as far as saying it is a fundamentally broken build system.
Chris

On Thu, May 26, 2011 at 9:24 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 25 May 2011 20:46, martin odersky <martin.odersky@epfl.ch> wrote:

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

Hope this clarifies things.

Best

 -- Martin

One very crucial difference being that JDK releases don't come in the form of Maven artefacts, so the JDK team don't have to worry about tooling compatibility for version numbers in quite the same way.
Using build numbers looks to be valid Maven AFAICT, but it's also a little-known feature; so I have some concerns that it may not be well supported across other third party tools that interact with Maven.  


Much more concerning is the naming inconsistency though, this is being publicised as "2.9.0.1" yet we'll all be using it as "2.9.0-1" from maven, sbt, etc.  Assuming that there are no technical difficulties caused by the convention, can we not at least name the release "2.9.0-1" everywhere.  Including blogs, wiki entries, email subjects, etc. to avoid any possible confusion?
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

I have found the following adequate for 99% of all my software version-ing needs.  Simple, clear semantics.  Everyone knows intent when a digit in the sequence bumps.
http://semver.org/
 
On Thu, May 26, 2011 at 7:35 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.
- Josh
On Thu, May 26, 2011 at 6:05 AM, Chris Marshall <oxbowlakes@gmail.com> wrote:

I love the fact that few seem to have considered the obvious: a build system that makes naming requirements of teams over which it has no control (and which may not use that system) is a build system with a problem. In fact, I might go as far as saying it is a fundamentally broken build system.
Chris

On Thu, May 26, 2011 at 9:24 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 25 May 2011 20:46, martin odersky <martin.odersky@epfl.ch> wrote:

For a language release, versioning is not as simple as it might appear to some folks. Here's the scheme we use, and will continue using.

First digit: Major, backwards incompatible change such as going from Python 2 to Python 3.

Second digit: Language stays source compatible. Libraries can do controlled breaking changes (usually accompanied by deprecation warnings). Binary compatibility is not guaranteed.

Third digit: Bug-fix release, or add new functionality to language and libraries. Binary compatibility is preserved. These come every 3-6 months, and they need RCs. They might contain 100 fixes or more, and might introduce new library packages or even smallish language additions.

Fourth digit like the one we just issued: Maintenance release for a small number of critical fixes. No RCs.

There's precedent for that: JDK releases also come with 4 digits.

Hope this clarifies things.

Best

 -- Martin

One very crucial difference being that JDK releases don't come in the form of Maven artefacts, so the JDK team don't have to worry about tooling compatibility for version numbers in quite the same way.
Using build numbers looks to be valid Maven AFAICT, but it's also a little-known feature; so I have some concerns that it may not be well supported across other third party tools that interact with Maven.  


Much more concerning is the naming inconsistency though, this is being publicised as "2.9.0.1" yet we'll all be using it as "2.9.0-1" from maven, sbt, etc.  Assuming that there are no technical difficulties caused by the convention, can we not at least name the release "2.9.0-1" everywhere.  Including blogs, wiki entries, email subjects, etc. to avoid any possible confusion?
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

On 26 May 2011 14:30, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

As Daniel said, this seems to create issue with SBT (Ivy-based) that don't take the update into account.
But after reading Todd explanation about the use of build number, I think it's an Ivy issue and not related at all with the use of build number in maven artifact version (can't test right now).
So after all that debate, I go for the: "Stay with four digit for hot-fixes".
Until we go for version 3 and then we could rethink the versioning strategy for maven artifact and perhaps move the major version to the artifactId (less impact than with minor version).
Cheers,
PS: 100% agree with Josh point on build tool's complains
--
Alois Cochardhttp://aloiscochard.blogspot.com http://twitter.com/aloiscochard

Sorry Martin,
I should clarify.  I think given that you wanted a 'hotfix' release, the version number was chosen correctly 2.9.0-1 however the advertised version number is 2.9.0.1.   That's the broken convention.   There was a time when labelled Scala releases did *not* match the numbers in the maven repository, but we have since corrected that.
The -N convention also has precedence in quite a few maven projects, but isn't used often outside of the specialized -SNAPSHOT magic (which ivy does support).
On Thu, May 26, 2011 at 8:30 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

On Thu, May 26, 2011 at 2:49 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Sorry Martin,
I should clarify.  I think given that you wanted a 'hotfix' release, the version number was chosen correctly 2.9.0-1 however the advertised version number is 2.9.0.1.  

OK, that should be easy to fix. -- Martin
 

That's the broken convention.   There was a time when labelled Scala releases did *not* match the numbers in the maven repository, but we have since corrected that.
The -N convention also has precedence in quite a few maven projects, but isn't used often outside of the specialized -SNAPSHOT magic (which ivy does support).
On Thu, May 26, 2011 at 8:30 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

On Thu, May 26, 2011 at 1:30 PM, martin odersky wrote:
> Can we get a concrete example of what breaks with the current four-digit
> versioning scheme? In our experiments so far everything goes smoothly.

There are 3 problems:

1. Version in announcement was different than version in Maven
repositories (as Josh pointed out).

2. Using the -N behaves differently in Maven versus tools that depend
on Ivy for dependence resolution (SBT is one such tool). The latter
tools won't do the automatic upgrade while the former ones will. One
more complication that needs to be explained to users.

3. Automatic updates are a _bad_ idea for non-snapshot dependencies.
It creates support problems as some users will run into issues and
others won't (and the only variable is when they executed their
build). Reproducible builds are a big deal.

Using the -N suffix is maybe OK if you issue a hotfix a few hours
after a release. Not a few weeks later in my opinion. In any case, I
use SBT, so I thankfully won't be affected by the automatic updates
and it seems like the version inconsistency will be fixed in a future
release. I still think the disadvantages are not worth the advantages,
but anyway.

Best,
Ismael

Also a note:  While maven will auto-magik-ly pull in 2.9.0-1 when 2.9.0 is specified, SBT will require 2.9.0-1 to be specified explicitly.  That perhaps is something Ivy can fix, but calling the release 2.9.0-1 would probably have alleviated  a lot of the surprise.
Also, Ismael makes a good point on consistency.  A lot of projects avoid issuing hot-fixes as hot-fixes but instead bug-fix releases.   As I may have stated earlier, I think a lot of this can be avoided if the RC process consistently has a 1-2 week period to vet bugs and if none show up, then that can become the release.   I think such a process could have avoided the first 2.9.0 such that 2.9.0-1 would have been the initial release.   I understand we live in the real world with deadlines and all, but based on scala's release history I also knew to wait for 2.9.1 (or in this case 2.9.0-1) before trying to port any 2.9 into google's codebase even though I'm desperately in need of a few bug fixes from 2.9.0 relating to generics and inheritance and package private evils.
- Josh

On Thu, May 26, 2011 at 8:52 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 2:49 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Sorry Martin,
I should clarify.  I think given that you wanted a 'hotfix' release, the version number was chosen correctly 2.9.0-1 however the advertised version number is 2.9.0.1.  

OK, that should be easy to fix. -- Martin
 

That's the broken convention.   There was a time when labelled Scala releases did *not* match the numbers in the maven repository, but we have since corrected that.
The -N convention also has precedence in quite a few maven projects, but isn't used often outside of the specialized -SNAPSHOT magic (which ivy does support).
On Thu, May 26, 2011 at 8:30 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

On Thu, May 26, 2011 at 3:11 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Also a note:  While maven will auto-magik-ly pull in 2.9.0-1 when 2.9.0 is specified, SBT will require 2.9.0-1 to be specified explicitly.  That perhaps is something Ivy can fix, but calling the release 2.9.0-1 would probably have alleviated  a lot of the surprise.
Also, Ismael makes a good point on consistency.  A lot of projects avoid issuing hot-fixes as hot-fixes but instead bug-fix releases.   As I may have stated earlier, I think a lot of this can be avoided if the RC process consistently has a 1-2 week period to vet bugs and if none show up, then that can become the release.   I think such a process could have avoided the first 2.9.0 such that 2.9.0-1 would have been the initial release.   I understand we live in the real world with deadlines and all, but based on scala's release history I also knew to wait for 2.9.1 (or in this case 2.9.0-1) before trying to port any 2.9 into google's codebase even though I'm desperately in need of a few bug fixes from 2.9.0 relating to generics and inheritance and package private evils.

It seems to me we are dealing with a catch-22 situation here. Because SBT and ivy-like tools don't do automatic upgrades, everybody has to build up dependent projects one by one for every new version, until large projects can be built. That takes a lot of time, and effort from the providers of these packages. It's natural to wait until final is out, but then serious bugs in large applications will only show up then, and that in turn necessitates hotfixes.

In the future, we plan to alleviate some of the problems by issuing milestones. But it will require the cooperation of the community. Milestones that are not used in anger are useless.

Cheers

 -- Martin


 

>>> Now, as for the 'maven package management system' a.k.a. maven
>>> repository.   The reason Maven limits things to three numbers is that it
>>> knowns when a particular version of a library is 'safe' to replace with
>>> another.

It's safe to replace 2.9.0 with 2.9.0-1, so I still don't see a problem here.

On Thu, May 26, 2011 at 8:41 AM, Alois Cochard wrote:
> But after reading Todd explanation about the use of build number, I think
> it's an Ivy issue and not related at all with the use of build number in
> maven artifact version (can't test right now).

I'm using Ivy for a personal project[*], and I did have to specify:

The + was the key to ensuring that I would get the one with the -1 suffix.

===

[*] I was using m2 previously, but getting Maven to do what I needed
was so difficult, that I was finally convinced recently to quit using
maven for all my projects. Since then, I've ripped m2 completely out
of my personal _and_ work projects, and uninstalled m2eclipse (which
has been getting progressively _less_ configurable, in true maven
form). I now use Ivy + Ant, which results in build configuration that
is human-readable and fits on a single screen -- unlike the previous
m2 configs which regularly produced pages' worth of gooey, useless
crap.

For me Ismael's #3 is the crux, to implicit patch or not.  If I define a specific build context, ideally I should achieve a repeatable, identical output artifact(s).  A referentially transparent build function if you will.   Consider if for any given build of the Scala compiler Oracle may or may not be implicitly patching the JVM behind the scenes.
On the other hand different tools will impose different versioning semantics, so you're damned if you do and if you don't for any given version pattern. 
I prefer the SBT/Ivy explicit approach where one can use a '+' to configure one's desired hotfix semantics auto/manual.  Given that, I have no issue with the 2.9.0-1 convention or 2.9.0.1  with a preference for the '-' approach, Maj.Min.Patch-HotFix as a pattern.  But that is a personal predilection.  Both work (for me).
On Thu, May 26, 2011 at 9:03 AM, Ismael Juma <ismael@juma.me.uk> wrote:

On Thu, May 26, 2011 at 1:30 PM, martin odersky <martin.odersky@epfl.ch> wrote:
> Can we get a concrete example of what breaks with the current four-digit
> versioning scheme? In our experiments so far everything goes smoothly.

There are 3 problems:

1. Version in announcement was different than version in Maven
repositories (as Josh pointed out).

2. Using the -N behaves differently in Maven versus tools that depend
on Ivy for dependence resolution (SBT is one such tool). The latter
tools won't do the automatic upgrade while the former ones will. One
more complication that needs to be explained to users.

3. Automatic updates are a _bad_ idea for non-snapshot dependencies.
It creates support problems as some users will run into issues and
others won't (and the only variable is when they executed their
build). Reproducible builds are a big deal.

Using the -N suffix is maybe OK if you issue a hotfix a few hours
after a release. Not a few weeks later in my opinion. In any case, I
use SBT, so I thankfully won't be affected by the automatic updates
and it seems like the version inconsistency will be fixed in a future
release. I still think the disadvantages are not worth the advantages,
but anyway.

Best,
Ismael

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

On 26 May 2011 14:25, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 3:11 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Also a note:  While maven will auto-magik-ly pull in 2.9.0-1 when 2.9.0 is specified, SBT will require 2.9.0-1 to be specified explicitly.  That perhaps is something Ivy can fix, but calling the release 2.9.0-1 would probably have alleviated  a lot of the surprise.
Also, Ismael makes a good point on consistency.  A lot of projects avoid issuing hot-fixes as hot-fixes but instead bug-fix releases.   As I may have stated earlier, I think a lot of this can be avoided if the RC process consistently has a 1-2 week period to vet bugs and if none show up, then that can become the release.   I think such a process could have avoided the first 2.9.0 such that 2.9.0-1 would have been the initial release.   I understand we live in the real world with deadlines and all, but based on scala's release history I also knew to wait for 2.9.1 (or in this case 2.9.0-1) before trying to port any 2.9 into google's codebase even though I'm desperately in need of a few bug fixes from 2.9.0 relating to generics and inheritance and package private evils.

It seems to me we are dealing with a catch-22 situation here. Because SBT and ivy-like tools don't do automatic upgrades, everybody has to build up dependent projects one by one for every new version, until large projects can be built. That takes a lot of time, and effort from the providers of these packages. It's natural to wait until final is out, but then serious bugs in large applications will only show up then, and that in turn necessitates hotfixes.

In the future, we plan to alleviate some of the problems by issuing milestones. But it will require the cooperation of the community. Milestones that are not used in anger are useless.

Cheers

 -- Martin

 I think not just milestones, but very explicitly named release candidates, so go through a cycle of betas and then RCs before releasing.  Usually 2-3 of each.
Technically, they may not mean a great deal, but psychologically I think that people attach a lot of significance to the "release" part of "release candidate".  It's as though being a beta implies that you're guaranteed to find bugs, so be gentle; but a release candidate is ready for you to kick the tyres in earnest, and sends a strong message that the final release is imminent so it's worth thinking about an upgrade.
A release candidate may even become the final with no change besides the name, and many developers are motivated by the idea of being one step ahead of their colleagues if that happens :)


--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On Thu, May 26, 2011 at 2:25 PM, martin odersky wrote:
> It seems to me we are dealing with a catch-22 situation here. Because SBT
> and ivy-like tools don't do automatic upgrades, everybody has to build up
> dependent projects one by one for every new version, until large projects
> can be built. That takes a lot of time, and effort from the providers of
> these packages.

As someone who did tested multiple RCs, it didn't take much time for
the base packages to be available (ScalaTest, specs, scalacheck for
me). Usually 24 hours. I compiled configgy manually and tested my
application. For RC1, there was a blocker bug that also affected
ScalaTest which prevented me from doing futher testing.

> It's natural to wait until final is out, but then serious
> bugs in large applications will only show up then, and that in turn
> necessitates hotfixes.

I tested my application with RC5 and found some bugs, including the
verifier issue when running in Tomcat. Sadly, the final came a day
after RC5 (while one of the issues was still being investigated and
before I had a chance to deploy the app). That's not enough time in my
opinion. I didn't test other RCs because I was on holiday between RC1
(which had a blocker) and RC5.

> In the future, we plan to alleviate some of the problems by issuing
> milestones. But it will require the cooperation of the community. Milestones
> that are not used in anger are useless.

And at least a week between the last RC and a release in my opinion.

Best,
Ismael

Concrete example (as mentioned): SBT cross-build.  While this isn't something that breaks per se, it's definitely a major inconvenience.

Regardless of whether or not Ivy2 supports the hotfix suffix scheme for versions, it certainly doesn't provide that support for artifact ids.  If we consider the following example of an artifact spec in SBT:

val specs2 = "org.specs2" %% "specs2" % "1.3"

This will only work if there is an artifact out there with an id of "specs2_2.9.0-1" (assuming that the project is being built against that version of Scala).  It won't resolve against "specs2_2.9.0".  For all intents and purposes, 2.9.0-1 is just as jarring of an upgrade as 2.9.1 would be.

In fact, it's somewhat more troublesome than 2.9.1.  Consider this expanded example:

val specs2 = "org.specs2" %% "specs2" % "1.3"
val scalaCheck = "org.scala-tools.testing" %% "scalacheck" % "1.8"

Now, Specs2 has a dependency on ScalaCheck, and they both have cross-builds handled by SBT.  However, because 2.9.0-1 is a hotfix release, ScalaCheck hasn't (yet) released a cross build for it, prompting specs2_2.9.0-1 to depend on scalacheck_2.9.0, in other words, manually circumventing the cross-build convention.  This is arguably justified since 2.9.0-1 is compatible with 2.9.0, but it causes a lot of problems for dependant cross-built projects which depend on both.  Basically, the above pair of dependencies cannot resolve when building with 2.9.0-1, even if ScalaCheck were to push a cross-build at this point.  The only way to get around this is to manually test the scalaVersion (a field provided by SBT) and generate the appropriate artifact suffix for ScalaCheck.  Not impossible, just annoying.

If the version had been 2.9.1, then I suspect framework authors would have been more conscientious about jumping on the version as a proper upgrade, rather than treating it as a hotfix.  We would have had the same issues with not automatically jumping up to the next version, but I'm not sure that's a bad thing.  The important point is that 2.9.0-1 is no less inconvenient than 2.9.1, and it has already given rise to some unfortunate dependency graphs due to the purported backwards compatibility.

Daniel

On Thu, May 26, 2011 at 7:30 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

On Thu, May 26, 2011 at 3:36 PM, Ismael Juma <ismael@juma.me.uk> wrote:

On Thu, May 26, 2011 at 2:25 PM, martin odersky <martin.odersky@epfl.ch> wrote:
> It seems to me we are dealing with a catch-22 situation here. Because SBT
> and ivy-like tools don't do automatic upgrades, everybody has to build up
> dependent projects one by one for every new version, until large projects
> can be built. That takes a lot of time, and effort from the providers of
> these packages.

As someone who did tested multiple RCs, it didn't take much time for
the base packages to be available (ScalaTest, specs, scalacheck for
me). Usually 24 hours. I compiled configgy manually and tested my
application. For RC1, there was a blocker bug that also affected
ScalaTest which prevented me from doing futher testing.

> It's natural to wait until final is out, but then serious
> bugs in large applications will only show up then, and that in turn
> necessitates hotfixes.

I tested my application with RC5 and found some bugs, including the
verifier issue when running in Tom

he app). That's not enough time in my
opinion. I didn't test other RCs because I was on holiday between RC1
(which had a blocker) and RC5.

Yes that's unfortunate. We'll do better in the future. RC5 was a last minute fix for some problems caused by RC4. That fix worked out OK. It's a bad coincidence that at the same time the much more serious tomcat problem which had been introduced prior to RC5 was discovered. Put it this way, with any release process there's a chance that a serious error will be discovered on the day the final is released. Nobody likes hotfixes but sometimes that's what you need to do.

Best,

 -- Martin

Hi All,

If the version had been 2.9.1, then I suspect framework authors would have been more conscientious about jumping on the version as a proper upgrade, rather than treating it as a hotfix.  We would have had the same issues with not automatically jumping up to the next version, but I'm not sure that's a bad thing.  The important point is that 2.9.0-1 is no less inconvenient than 2.9.1, and it has already given rise to some unfortunate dependency graphs due to the purported backwards compatibility.

I have kept ScalaTest's Scala project dependencies minimal so that I don't have to wait for many projects to build with a new version of Scala before I can make a new ScalaTest release against that new Scala version. My only dependency is ScalaCheck, so I was unable to release a build against 2.9.0 until I got a ScalaCheck build for 2.9.0.

Nevertheless, my understanding of EPFL's promise that minor releases are binary compatible is that you don't need another build of any of the libraries built against 2.9.0. For example, ScalaTest 1.4.1, which was built against 2.9.0, should be binary compatible with 2.9.0-1 and will be with releases such as 2.9.1, 2.9.2, and 2.9.3, if and when those appear.

One ScalaTest user requested I release new builds anyway for point releases, because they didn't fully trust EPFL's binary compatibility promise. But I think we need to trust it. If a particular point release of Scala turns out to be not binary compatible with the previous ones, that's a bug in that release and needs to be fixed in a subsequent release.

So my thought with sbt is maybe it could be enhanced with another operator or some syntax that gives you the kind of search back for a build against the most recent binary compatible release of Scala.

Bill
 

Daniel

On Thu, May 26, 2011 at 7:30 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Thu, May 26, 2011 at 1:35 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

There's a misrepresentation here.   Maven is, in fact, two things: A Build system *and* a package management system for the JVM.
The version bit comes into place for the package management poriton, which also affects Ivy and therefore SBT.   If you want to imply that version number requirements for package management systems are a bad idea, then don't bother to continue reading.  I'd also encourage you to design a new package system with no such impediments!
Now, as for the 'maven package management system' a.k.a. maven repository.   The reason Maven limits things to three numbers is that it knowns when a particular version of a library is 'safe' to replace with another.   Say I have project Z which depends on project X and Y.   Project Y also depends on X, however it uses a different version than was used on Project Z.    A good package manager will try to help avoid DLL-hell by resolving X, Y and Z such that everyone is happy.   IN this vein, maven (the package manager) will automatically pick the 'latest/safest' version number of an artifact for runtime, where safe is defined as only differing by binary compatible changes.  The maven repository asks that you encode this in your version system.
As users use this package management, in Ivy, SBT and Maven, they begin to enjoy the relative easy of development and dependency management that can be achieved with a common convention.   This is an instance of a project violating that convention (again) and the community using the 'pestering' technique to try to make the project fall in line so that things will work as expected.
In any case, feel free to blame maven for being a package management system, but I think stating that a package management system should not care about versions would imply that all package management systems are going about things the wrong way.   Granted, I haven't seen a 'perfect' package management system yet, but the ones that use versions are the ones I use daily.

Can we get a concrete example of what breaks with the current four-digit versioning scheme? In our experiments so far everything goes smoothly.

The idea to encode the major version number of the Scala language in the artefact name is interesting but would completely break all previous practice.

If we do not want to do that, we are left with only two choices:

 - Use the third digit for both regular, binary compatible releases and hotfixes. But the two are pretty different. Regular releases have RCs, hotfixes don't. Regular releases are major increments, and you might want to wait with an upgrade. To hotfixes you should upgrade quickly and as automatically as possible, because they fix some serious errors in the previous release.

 - Or, use a fourth digit for hotfixes.

Pick your poison :-) But before considering changing again I want to see something concrete that breaks with the current scheme.

Thanks

 -- Martin

--
Bill Venners
Artima, Inc.
http://www.artima.com