Phoenix - demo.version.py

[Werner]

Hi,

could the build scripts update above file to e.g.:
VERSION_STRING = '3.0.1.dev75695'

Werner

[Metallicow]

Post by Werner
Hi,
VERSION_STRING = '3.0.1.dev75695'
Werner

Should the demo/version.py file be maintained in the source repository? Or

Post by Werner
just let it always be generated like wx/__version__.py?

I think that was the plan, but am not sure if Robin decided on how to
exactly handle it, or maybe it hasn't been hooked in yet. It is on the
Phoenix TODO to decide at one point.

[Robin Dunn]

Post by Werner
Hi,
VERSION_STRING = '3.0.1.dev75695'
Werner
Should the demo/version.py file be maintained in the source
repository? Or just let it always be generated like wx/__version__.py?
I think that was the plan, but am not sure if Robin decided on how to
exactly handle it, or maybe it hasn't been hooked in yet. It is on the
Phoenix TODO to decide at one point.

The build.py script has a setrev command which will try to find out the
current SVN revision from the svnversion command, or from git-svn, or it
will fall back to using the current date. That value will be written to
a REV.txt file in the root of the Phoenix source tree, and the contents
of REV.txt will then be used to construct the version number used in the
rest of the build and also when wx/__version__.py and demo/version.py
are written.

Werner, are you seeing a case where the revision number in the generated
files or the egg filename don't match up? Or is it the fact that what
is in the repository does not have the revision number appended?

I had originally started committing the version.py with the rev number
included, but the simple fact that committing the file would then
increment the rev number, making the file be out of date before it could
even be downloaded by anyone makes it seem kind of silly to do so.
Instead the buildbot builders will run the setrev command as part of the
build, and will include the generated REV.txt and version py files in
the source tarball, making it be tied to the revision that was used to
do the build. For local development I usually don't worry about the
revision number at all and have no REV.txt, unless I am testing building
distributables or something.

[Werner]

Hi Robin,

On 27/01/2014 01:51, Robin Dunn wrote:

...

Post by Robin Dunn
Werner, are you seeing a case where the revision number in the
generated files or the egg filename don't match up? Or is it the fact
that what is in the repository does not have the revision number
appended?

No, it was only in the repo and I understand now why it can't match.

Thanks
Werner

[Metallicow]

Post by Werner

Post by Werner
Hi,
VERSION_STRING = '3.0.1.dev75695'
Werner
Should the demo/version.py file be maintained in the source
repository? Or just let it always be generated like

wx/__version__.py?

Post by Werner
I think that was the plan, but am not sure if Robin decided on how to
exactly handle it, or maybe it hasn't been hooked in yet. It is on the
Phoenix TODO to decide at one point.

The build.py script has a setrev command which will try to find out the
current SVN revision from the svnversion command, or from git-svn, or it
will fall back to using the current date. That value will be written to
a REV.txt file in the root of the Phoenix source tree, and the contents
of REV.txt will then be used to construct the version number used in the
rest of the build and also when wx/__version__.py and demo/version.py
are written.
Werner, are you seeing a case where the revision number in the generated
files or the egg filename don't match up? Or is it the fact that what
is in the repository does not have the revision number appended?
I had originally started committing the version.py with the rev number
included, but the simple fact that committing the file would then
increment the rev number, making the file be out of date before it could
even be downloaded by anyone makes it seem kind of silly to do so.
Instead the buildbot builders will run the setrev command as part of the
build, and will include the generated REV.txt and version py files in
the source tarball, making it be tied to the revision that was used to
do the build. For local development I usually don't worry about the
revision number at all and have no REV.txt, unless I am testing building
distributables or something.
--
Robin Dunn
Software Craftsman
http://wxPython.org

umm, whatever magic wand you are wielding...
please do it right. Sounds cool and right, so, go with it. Impress us.