aboutsummaryrefslogtreecommitdiffstats
path: root/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/c35835c0-8f9f-4090-ba92-1f616867e486/body
blob: d8014d2a177f6517583ae53566790ca2e2322c5b (plain) (blame)
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