I would really like to have a version number for development snapshots of DMD like: 2.060-devel-HASH, where HASH is the hash of the HEAD commit used to compile the compiler.

The VERSION file should hold the string 2.060-devel and the hash will be automatically appended. An optional symbol will be used (like +) to indicate a dirty working tree (a working tree with uncommitted changes). The extra hash will only be appended if the version string ends with -devel, so when releasing it should be enough to remove the -devel suffix from the version file to make all the devel information go away.

I notice some work was done (and undone) about the version number lately. So before issuing a pull request I want to ask two questions:

1. Would such a pull request be accepted?
2. I don't have a test environment for win32, and I don't know if it's
   even possible to execute a command there and get its output, do you
   know if that's possible? And if not, or is very complex, would it be
   acceptable to have this full devel version with a hash reported in
   POSIX but not in win32? Remember this is only for devel releases
   (which I hope includes beta releases, and potentially nightly build,
   if those even happen).

Thank you.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Ya ni el cielo me quiere, ya ni la muerte me visita
Ya ni el sol me calienta, ya ni el viento me acaricia
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/6/2013 9:46 AM, Leandro Lucarella wrote:
> I would really like to have a version number for development snapshots
> of DMD like: 2.060-devel-HASH, where HASH is the hash of the HEAD commit
> used to compile the compiler.
>
> The VERSION file should hold the string 2.060-devel and the hash will be
> automatically appended. An optional symbol will be used (like +) to
> indicate a dirty working tree (a working tree with uncommitted changes).
> The extra hash will only be appended if the version string ends with
> -devel, so when releasing it should be enough to remove the -devel
> suffix from the version file to make all the devel information go away.
>
> I notice some work was done (and undone) about the version number
> lately. So before issuing a pull request I want to ask two questions:
>
> 1. Would such a pull request be accepted?
> 2. I don't have a test environment for win32, and I don't know if it's
>     even possible to execute a command there and get its output, do you
>     know if that's possible? And if not, or is very complex, would it be
>     acceptable to have this full devel version with a hash reported in
>     POSIX but not in win32? Remember this is only for devel releases
>     (which I hope includes beta releases, and potentially nightly build,
>     if those even happen).
>
> Thank you.

I want to use VERSION for much more than just generating a .h file, and having more information in there would mess that up.

What use do you intend for this change?
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  6 de February a las 10:42 me escribiste:
> >Thank you.
> 
> I want to use VERSION for much more than just generating a .h file, and having more information in there would mess that up.
> 
> What use do you intend for this change?

All comes down to reliably determining the version of any dmd
executable.

My particular need to need that information is because we sometimes end
up using different internal versions because we need some bug fixed
before an official release and currently is impossible.

For the community I think this will be good for bug reports of
non-releases. Personally I also find myself using some binary while
developing and don't remember which exact version that binary was
compiled from.

Is a very common thing in big opensource projects too, and it will be
specially useful for people reporting bugs for some unreleased version,
either for betas or, as I said, if at some point in the future we ship
nightly snapshots.

Finally, I find particularly irritating that the version is not
dependable. If you have a compiler with version X, then that compiler
could be produced from any moment in the history of the source between
X and X-1. Part of the job of the SCM is to keep track of the revisions
of a program, and currently we are not taking advantage from that
information.

May I ask what other uses do you have in mind for VERSION? Do you think
they could not benefit too from having a more accurate version (or even
that it will have a negative impact)?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Me encanta el éxito; por eso prefiero el estado de progreso constante,
con la meta al frente y no atrás.
	-- Ricardo Vaporeso. Punta del Este, Enero de 1918.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/6/2013 3:12 PM, Leandro Lucarella wrote:
> May I ask what other uses do you have in mind for VERSION? Do you think they could not benefit too from having a more accurate version (or even that it will have a negative impact)? 

I have several makefiles and install files that take the version number as an argument - it's been a giant error-prone pain to do this, and Andrei suggested a single VERSION file to take its place.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  6 de February a las 21:52 me escribiste:
> 
> On 2/6/2013 3:12 PM, Leandro Lucarella wrote:
> >May I ask what other uses do you have in mind for VERSION? Do you think they could not benefit too from having a more accurate version (or even that it will have a negative impact)?
> 
> I have several makefiles and install files that take the version number as an argument - it's been a giant error-prone pain to do this, and Andrei suggested a single VERSION file to take its place.

And you use these only when releasing or in your daily routine too?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
PADRES DENUNCIAN QUE SU HIJA SE ESCAPO CON UN PARAGUAYITO
	-- Crónica TV
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Leandro Lucarella, el  7 de February a las 13:49 me escribiste:
> Walter Bright, el  6 de February a las 21:52 me escribiste:
> > 
> > On 2/6/2013 3:12 PM, Leandro Lucarella wrote:
> > >May I ask what other uses do you have in mind for VERSION? Do you think they could not benefit too from having a more accurate version (or even that it will have a negative impact)?
> > 
> > I have several makefiles and install files that take the version number as an argument - it's been a giant error-prone pain to do this, and Andrei suggested a single VERSION file to take its place.
> 
> And you use these only when releasing or in your daily routine too?

Since betas are starting to flowing, it will be a good oportunity to do this. So any input for me to know how to do it in a way that it works for everyone would be appreciated. Or is there no interest at all on having a proper version information in the binary...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
¿Qué será lo que hace que una brújula siempre marque el norte?
- Ser aguja, nada más, y cumplir su misión.
	-- Ricardo Vaporeso
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/8/2013 2:19 AM, Leandro Lucarella wrote:
> Leandro Lucarella, el  7 de February a las 13:49 me escribiste:
>> Walter Bright, el  6 de February a las 21:52 me escribiste:
>>> On 2/6/2013 3:12 PM, Leandro Lucarella wrote:
>>>> May I ask what other uses do you have in mind for VERSION? Do you
>>>> think they could not benefit too from having a more accurate
>>>> version (or even that it will have a negative impact)?
>>> I have several makefiles and install files that take the version
>>> number as an argument - it's been a giant error-prone pain to do
>>> this, and Andrei suggested a single VERSION file to take its place.
>> And you use these only when releasing or in your daily routine too?
> Since betas are starting to flowing, it will be a good oportunity to do
> this. So any input for me to know how to do it in a way that it works
> for everyone would be appreciated. Or is there no interest at all on
> having a proper version information in the binary...

If you only want it in the binary, then put it in a .h file. VERSION is used for other things as well as generating binaries - that's the whole point of it. It's not scriptable if I have to do it by hand each time.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  8 de February a las 03:03 me escribiste:
> 
> On 2/8/2013 2:19 AM, Leandro Lucarella wrote:
> >Leandro Lucarella, el  7 de February a las 13:49 me escribiste:
> >>Walter Bright, el  6 de February a las 21:52 me escribiste:
> >>>On 2/6/2013 3:12 PM, Leandro Lucarella wrote:
> >>>>May I ask what other uses do you have in mind for VERSION? Do you think they could not benefit too from having a more accurate version (or even that it will have a negative impact)?
> >>>I have several makefiles and install files that take the version number as an argument - it's been a giant error-prone pain to do this, and Andrei suggested a single VERSION file to take its place.
> >>And you use these only when releasing or in your daily routine too?
> >Since betas are starting to flowing, it will be a good oportunity to do this. So any input for me to know how to do it in a way that it works for everyone would be appreciated. Or is there no interest at all on having a proper version information in the binary...
> 
> If you only want it in the binary, then put it in a .h file.  VERSION is used for other things as well as generating binaries - that's the whole point of it. It's not scriptable if I have to do it by hand each time.

I think it would be good to be anywhere else where a version string is
used, but even then I wasn't planning to put it in the VERSION file,
I suggested to use the VERSION file to indicate if the extra git hash
should be specified, by adding the -devel suffix. When you want to make
a release and remove the extra development version information, just
remove the suffix from the VERSION file.

If you want to keep the VERSION file without the -devel suffix always,
I can come up with a different way to do it (a header file doesn't seems
like a good idea because this information is not static, is taken from
the output of a git command). I could add a Make variable to append this
information and you can do something like make RELEASE=1 to build
a release binary.

I think the way to go is to completely get rid of any VERSION file and use git to set version numbers through tags, but one step at the time ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Fry: Since when is the internet about robbing people of their privacy?
Bender: August 6th, 1991.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 2/8/2013 3:34 AM, Leandro Lucarella wrote:
> Walter Bright, el  8 de February a las 03:03 me escribiste:
>> On 2/8/2013 2:19 AM, Leandro Lucarella wrote:
>>> Leandro Lucarella, el  7 de February a las 13:49 me escribiste:
>>>> Walter Bright, el  6 de February a las 21:52 me escribiste:
>>>>> On 2/6/2013 3:12 PM, Leandro Lucarella wrote:
>>>>>> May I ask what other uses do you have in mind for VERSION? Do you
>>>>>> think they could not benefit too from having a more accurate
>>>>>> version (or even that it will have a negative impact)?
>>>>> I have several makefiles and install files that take the version
>>>>> number as an argument - it's been a giant error-prone pain to do
>>>>> this, and Andrei suggested a single VERSION file to take its place.
>>>> And you use these only when releasing or in your daily routine too?
>>> Since betas are starting to flowing, it will be a good oportunity to do
>>> this. So any input for me to know how to do it in a way that it works
>>> for everyone would be appreciated. Or is there no interest at all on
>>> having a proper version information in the binary...
>> If you only want it in the binary, then put it in a .h file.  VERSION
>> is used for other things as well as generating binaries - that's the
>> whole point of it. It's not scriptable if I have to do it by hand each
>> time.
> I think it would be good to be anywhere else where a version string is
> used, but even then I wasn't planning to put it in the VERSION file,
> I suggested to use the VERSION file to indicate if the extra git hash
> should be specified, by adding the -devel suffix. When you want to make
> a release and remove the extra development version information, just
> remove the suffix from the VERSION file.
>
> If you want to keep the VERSION file without the -devel suffix always,
> I can come up with a different way to do it (a header file doesn't seems
> like a good idea because this information is not static, is taken from
> the output of a git command). I could add a Make variable to append this
> information and you can do something like make RELEASE=1 to build
> a release binary.
>
> I think the way to go is to completely get rid of any VERSION file and
> use git to set version numbers through tags, but one step at the time ;)
>

VERSION drives git, not the other way around!
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Walter Bright, el  8 de February a las 10:02 me escribiste:
> >I think the way to go is to completely get rid of any VERSION file and use git to set version numbers through tags, but one step at the time ;)
> >
> 
> VERSION drives git, not the other way around!

No, is definitely the other way around. That's why you have a version control system.

But never mind, I just want a binary with full version information for development snapshots. Is there any way to convince you to accept having that? Something needs to be changed, a way to differentiate releases from development snapshots.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
For me to ask a woman out, I've got to get into a mental state like the
karate guys before they break the bricks.
	-- George Constanza
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals