It looks like some variables are not expanded correctly. Joys of untyped programming! :)

I discovered this as well. It's caused by fbd5efe49cf23b446762dfa5026e8bac82ab04fc. I might be missing something but I don't understand why build.properties was causing troubles. If we decide this is a right way to move forward publishing nightlies should be easy to fix (you need look into src/maven).
-- Grzegorz Kossakowski

I discovered this as well. It's caused by fbd5efe49cf23b446762dfa5026e8bac82ab04fc. I might be missing something but I don't understand why build.properties was causing troubles. If we decide this is a right way to move forward publishing nightlies should be easy to fix (you need look into src/maven).

Actually, the file is src/build/maven/pack.xml and it's not that easy to fix as I thought because it really needs those version.major, version.minor, version.patch variables to construct proper Maven version.

I discovered this as well. It's caused by fbd5efe49cf23b446762dfa5026e8bac82ab04fc. I might be missing something but I don't understand why build.properties was causing troubles. If we decide this is a right way to move forward publishing nightlies should be easy to fix (you need look into src/maven).

Actually, the file is src/build/maven/pack.xml and it's not that easy to fix as I thought because it really needs those version.major, version.minor, version.patch variables to construct proper Maven version.

Sure. Also, since we are going through next iteration over build numbers I should mention needs of projects like Scala virtualized or Scala+GWT where we want to put a suffix after patch version that disambiguates snapshots of those project from main Scala. E.g. version numbers used by those projects are:
2.10.0-virtualized-SNAPSHOT2.10.0-scalagwt-SNAPSHOT

The manual construction in ant was competing with git-describe to
create the version number (there's a period there where they look like
v2.10.0-v2.10.0-...) so in order to use git describe I had to remove
it from ant. I don't like leaving unused misleading stuff lying
around to leave the next guy trying to figure out what if anything it
does (having been "the next guy" most of the time, and the answer
usually is "it does nothing, but nobody ever removes anything") and I
searched the source tree and there was no direct mention of the file,
so I removed it too. I realized it could be being used in a way which
didn't mention the file, as it seems it was, but I didn't think to
search for the property names.

The manual construction in ant was competing with git-describe to
create the version number (there's a period there where they look like
v2.10.0-v2.10.0-...) so in order to use git describe I had to remove
it from ant.

Ah, ok. Now it makes perfect sense. That was the bit I was missing in the commit message :-)

I don't like leaving unused misleading stuff lying
around to leave the next guy trying to figure out what if anything it
does (having been "the next guy" most of the time, and the answer
usually is "it does nothing, but nobody ever removes anything") and I
searched the source tree and there was no direct mention of the file,
so I removed it too. I realized it could be being used in a way which
didn't mention the file, as it seems it was, but I didn't think to
search for the property names.

Sure, no worries. Now the most important question is: how we can make everything working again?Parsing output of git describe output seems like the only viable option...

As long as the major/minor/bugfix versions are in ANT memory properties, they'll get written to a build.properties file for the maven scripts to push them correctly.Note: The version we show in our scala.properties does not, and has never lined up with the published version. I'm not sure what the motivation was for removing them, since as far as i know, they should not have been mucking with any versions in the build.
This is yet another reason I'd like to finally kick ANT and move to SBT. yes, I know that in a land where SBT can't compile against trunk, it's impossible to do so. However, these kinds of issues are handled far easier and more elegantly in SBT. I'm over here making MSI packages assuming everything is going swimmingly, but instead we have 2 and a half build systems to maintain, and I'm pretty sure the SBT build is not using the new versioning strategy. We really need to move to one or the other. For the upcoming 2.10 release, I need to know what input to expect to build the native packages, and there's subtle differences in what ANT does vs. SBT.
- Josh

On Fri, Feb 3, 2012 at 6:34 AM, Grzegorz Kossakowski
<grzegorz [dot] kossakowski [at] gmail [dot] com> wrote:
> Sure, no worries. Now the most important question is: how we can make
> everything working again?

yes, that's the URL the nightlies were published to for years. Since a few weeks it doesn't point to the trunk ScalaDocs anymore, but to 2.9.2 instead. No idea why, considering that API changes between 2.9.1 and 2.9.2 might be non-existent to negligible. Any chance to fix it and point it to trunk again?

Sorry, I was too fast. I see there are two competing pull requests, none of which is merged yet. Someone (other than Mr. Jenkins) has built and pushed to scala-tools, and that's what I saw earlier..
iulian

I made another pull request to remove the 'v' in the version number (v2.10.0-... becomes 2.10.0...). Unfortunately most (all?) tools assume that the first three components of a version are actual numbers, and Eclipse is one of them. So in order to keep the beast happy, we need to sacrifice the first 'v' in our version string.
For the record, our version strings before this change didn't have the 'v' either.iulian