1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
On Thu, Jul 16, 2009 at 07:32:31PM +1000, Ben Finney wrote:
> "W. Trevor King" <wking@drexel.edu> writes:
>
> > On Wed, Jul 15, 2009 at 12:54:05AM +1000, Ben Finney wrote:
> > > "W. Trevor King" <wking@drexel.edu> writes:
> > >
> > > > On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
> > > > > Please, no. Timestamps aren't version strings, that's conflating
> > > > > two pieces of information with very different meanings.
> > > > > Correlating the two is the job of a [NEWS file].
> >
> > > If you want a monotonically-increasing indicator of which revision
> > > we're up to, that's immediately available with the revision number
> > > from VCS on the main branch. That also has the advantage of
> > > producing consecutive numbers for each revision, by definition.
> >
> > But not during branch-switches, while my method skips large regions,
> > but probably increases during any reasonable branch-switch.
>
> I've read this several times now, and I don't see what it's saying.
>
> The assumption I'm making is that there is a single canonical “main
> branch”, from which releases will be made.
I don't think you need to assume this. See my "virtual branch"
argument below.
> The version number set in that branch is the one which determines
> the version of Bugs Everywhere as a whole.
If you are suggesting that the dev branches adjust their release
number _by_hand_ to match the current trunk release number, that
allows switching, but sounds like a lot of work and isn't correct
anyway, since they are not in the same state as the trunk.
> The revision number is only useful in the context of the branch, so it
> only matters when comparing versions within a branch. When you switch
> between branches, if you're interested in the revision number you'll
> still need to know which branch you're talking about.
I think this is our main disagreement. I see all the branches as part
of the same codebase, with monotonically increasing timestamp patch
numbers. If you were to collapse all the commit snapshots down into a
single chronological "virtual branch", it would still make sense, it
would just be a bit unorganized. We do all try to move in the same
general direction ;).
> Switching between branches doesn't change the canonical version string.
Different released code should have different version numbers.
> > For example, when I upgraded to rich root to pull Ben's patch, I'm not
> > sure if Chris upgraded the trunk and merged my branch, or just ditched
> > the trunk and cloned my branch. Using actual bzr revision numbers
> > would make switching branches that either wrong (in the case of rev-id
> > decreases) or confusing (in the case of a single non-consecutive
> > increase).
>
> This, then, is an argument for not having the revision number in the
> version string at all. The version then becomes a more traditional
> “major.minor.patch” tuple, and is only ever updated when some release
> manager of the canonical branch decides it's correct to do so.
It is an argument for not using the revision number. You can avoid
revision numbers by using hand-coded patch numbers, or by using
timestamps, which is what we're trying to decide on :p.
> If we use the ‘bzr version-info --format=python > foo_version.py’
> command in some build routine, the branch's revision number will be
> available directly within Python by importing that module. That would
> allow it to be output in some UI, if that's what you're interested in
> seeing.
True. Which means that whichever version string wins out, the other
side will still be able to access the info we both want included ;).
We can certainly suggest that bug reporters submit their
be --verbose-version
when they submit bugs. The only role of the official "version string"
is to make life easy for packagers. If they woln't be switching
branches, then either of our proposals are fine. If they will, then
I think timestamps work better.
--
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
|
