minor version change to trunk

2 views
Skip to first unread message

Chris Clark

unread,
May 26, 2009, 8:04:06 PM5/26/09
to prettyta...@googlegroups.com
See verchange.patch for a suggestion on dealing with version numbers in
trunk.

For some reason the version of setuptools I have is freaking out with
the svn working copy format (probably an svn version mismatch as I
updated my svn client but I've not yet double checked my pysvn libs) so
I've not actually tested this as an egg yet. See verchange_dist.patch
for a quick hack that probably isn't appropriate for submission but
worked locally for me to do a simple "setup.py sdist".

Chris

verchange_dist.patch
verchange.patch

Luke Maurits

unread,
May 27, 2009, 5:39:22 AM5/27/09
to prettytable-devel
Hi Chris,

I very much like the idea of having the version set in setup.py to be
the value of a __version__ variable in prettytable.py, since it means
we only need to update the version number in one place each release
instead of two. I will commit this shortly.

I'm not so sure I like __version__ = "0.6alpha" in the trunk, though,
although I'm quite open to persuasion if there is actually some
benefit to this. From my point of view: If __version__ is just
"TRUNK" in trunk, then after branching trunk to, say, 0.6, we need to
change __version__ to 0.6 in that branch but can leave trunk alone -
i.e. one change per branching. In contrast, if __version__ is
"0.6alpha" in trunk, then after branching trunk to 0.6 we need to
change __version__ in that new branch AND in trunk (to 0.7alpha, in
this case) - i.e. two changes per branching. I feel it would be best
to minimise the number of required changes per chance (and hence
minimise the probability of forgetting one) as long as we can do this
without causing any problems.

Of course, if you can make a good argument for why having __version__
= "TRUNK" in trunk is bad I'm more than happy to consider it.

Thanks for your input.

Luke
Reply all
Reply to author
Forward
0 new messages