- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: tools/get-scala-revision.bat is broken
Sun, 2012-01-29, 22:30
On Sun, Jan 29, 2012 at 12:33 PM, iulian dragos wrote:
> The IDE only needs to have a monotonically increasing sequence of
> version numbers.
Where "increasing" is measured by...
If it figures out that 2.10 is later than 2.9 then I take it that it
is number-aware.
> v2.10.0-M1-75-g91f82dfaaf-
>
> The date would be useful when dealing with daily snapshots, indeed.
> But it should come before the git hash, to ensure proper ordering.
That's what the "75" in the above is for. That's guaranteed to be
increasing for as long as it's describing against the same tag. It
would reset to 0 when we tag v2.10.0-M2, but I assume it figures out
that M2 is later than M1. Using the date doesn't even guarantee
proper ordering, because a commit can be dated earlier than its
parent, and if it's the date on which it was built it means even less
than the date of the commit.
Fri, 2012-02-03, 15:41
#2
Re: tools/get-scala-revision.bat is broken
On Fri, Feb 3, 2012 at 2:43 AM, iulian dragos wrote:
> BTW, it looks like there are no more nightlies pushed out to scala-tools.
> The last one is on Feb 1st, while the nightly build is not failing. Could it
> be this version string that broke it?
I take it from the other thread that I broke it by removing the
build.number file. I don't think it's related to the version string
per se.
Fri, 2012-02-03, 19:51
#3
Re: tools/get-scala-revision.bat is broken
Yes. build.number was used by the maven-publishing code. Again, we have two versions. The one in {library,compiler}.properties and the one used to publish to the maven repositories.
On Fri, Feb 3, 2012 at 9:32 AM, Paul Phillips <paulp@improving.org> wrote:
On Fri, Feb 3, 2012 at 9:32 AM, Paul Phillips <paulp@improving.org> wrote:
On Fri, Feb 3, 2012 at 2:43 AM, iulian dragos <iulian.dragos@epfl.ch> wrote:
> BTW, it looks like there are no more nightlies pushed out to scala-tools.
> The last one is on Feb 1st, while the nightly build is not failing. Could it
> be this version string that broke it?
I take it from the other thread that I broke it by removing the
build.number file. I don't think it's related to the version string
per se.
On Mon, Jan 30, 2012 at 1:41 AM, iulian dragos wrote:
> The problem is that the qualifier is a string, therefore v2.10.0-M1-2
>> v2.10.0-M1-10. If you can pad it somehow, it would work.
Well, I sure feel like I'm doing it wrong if nobody else has ever run
into this, but with a little dose of bash magic, they now look like
this:
v2.10.0-M1-0098-g6f1c486d0b-2012-02-01
> I don't understand the last part. I was thinking to use the date/time
> of the build, which is the only thing that works reliably in my
> knowledge.
But what is the date/time of the build? Do you mean the time at which
it is built? The problem is that there is only an incidental
correlation between that time and the compilation products. I can
check out any revision and build it today. I realize that under
normal circumstances this correlation will exist, I'd just rather not
depend on it existing for correctness.
The same problem exists, less severely, with using the date on the
commit. To my knowledge there is nothing which guarantees that some
revision succeeds some other revision, except: when one exists within
the history of the other.