Re: [Sablevm-developer] Release progress - problems w/ 'make distcheck' of classpath

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

>>Seems okay.  Except that staging changes frequently, so I suspect that 
>>when the version really does matter, we'll end up referring to it by 
>>revision number (e.g. staging-r1575).  I'm not even sure if `1.0.9' or 
>>`1.1.0' is necessary in the name ... isn't it just obvious that staging 
>>is changes against bugfree at all times, which in turn is changes 
>>against the latest release?> 
> 
> I tried to use the subversion's magic string substitution or even the
> svnversion utility to put the revision number there, but I am afraid
> it can't be done easily, unless we want to generate configure.ac from
> some other file or sth. like that (hmm... maybe use sed and generate
> it from itself in ./autogen.sh and on make dist? feel free to try it!)

Okay, I'll try it if I need a break :)  It seems like it could be quite 
useful ...

> But I am sure staging shouldn't claim to be just "1.0.9" or any other
> release. I wanted to put "staging" name initialy, but I guess
> "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give
> some more informations if we ask a user to do 'sablevm -V' for us.

Well, /only/ because I find this oddly interesting ... I see it as:

staging == 1.0.9 + new changes == 1.0.9 + (staging - 1.0.9) == staging

>>I think staging needs to be frozen with respect to SableVM functionality 
>>once the regression tests have started until the big merge into bugfree 
>>is made.  But then I don't know -- do you want critical fixes to bugfree 

I meant, do you think the freeze should expire once the merge to bugfree 
is complete?  Or once the release is made?  Or once something else?  It 
sounds like you're saying once the merge is complete.

Cheers,
Chris