Phoenix - demo.version.py

Hi,

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

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.

···

On Friday, January 24, 2014 1:29:32 PM UTC-6, werner wrote:

Hi,

could the build scripts update above file to e.g.:

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?

Metallicow wrote:

    Hi,

    could the build scripts update above file to e.g.:
    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.

···

On Friday, January 24, 2014 1:29:32 PM UTC-6, werner wrote:

--
Robin Dunn
Software Craftsman

Hi Robin,

...

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

···

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

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

···

On Sunday, January 26, 2014 6:51:24 PM UTC-6, Robin Dunn wrote:

Metallicow wrote:

On Friday, January 24, 2014 1:29:32 PM UTC-6, werner wrote:

Hi,
could the build scripts update above file to e.g.:
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.


Robin Dunn

Software Craftsman

http://wxPython.org