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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
On Thursday 16 July 2009 12:38:55 W. Trevor King wrote:
> 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.
But if we have a canonical "main branch" that we release, and the packager
get, we can refer to it as the stable branch, that it is not a bad idea.
> > 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 version number of trunk _is_ should be the official version number of the
Bugs Everywhere releases.
The version number in branch does not means nothing outside the branch.
At least we can have a mechanism to build a version number scheme that is
consistent for us to be able to merge branch easily.
> > 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 ;).
I don't think that, outside the developers, a version number like
cjb@laptop.org-20090713154540-ve4pmydqzb1ghgvc
is a good choice, not for the user of BE, not for the packager of BE
> > 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.
We can use both.
During the development we can use version number like
x.y.z.timestamp
As we decide to release a stable version, the release manager set the version
number to a more traditional x.y.z format, and create a branch (stable branch)
This way we have these advantages:
1) an user have a simple version number to use for bug report/feature
request/help request
2) a packager have an easy life to choose to package a stable or a trunk
version, knowing what are they doing
bonus) we can maintain a stable and a developmente source tree/branch, where
in the development tree we can make also backward incompatible modification to
the source without making any damage to the users/packagers, while in the
stable branch we can make only bugfix/security fix or port from the devel branch
some interesting features as long as they don't break compatibility.
bye
Gianluca
_______________________________________________
Be-devel mailing list
Be-devel@bugseverywhere.org
http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
|
