Joel Brobecker
2018-09-10 08:49:34 UTC
Hello,
During this year's GNU Cauldron, we discussed the version numbering
scheme the GDB project has been following so far, because a number
of users were confused by it.
At the moment, as you know, GDB's version number is composed of at
least 2 numbers (MAJOR.MINOR) with an optional micro version suffix
(MAJOR.MINOR.MICRO). During each release cycle, we usually increase
the minor number. For instance, since the last release branch was
an 8.2 branch, the next GDB release branch is currently expected to
be 8.3.
The problem with that numbering is that a number of users got confused
by that numbering, thinking that all releases made with the same MAJOR
number were made from the same release branch. So, they thought for
instance that 8.0, 8.1 and 8.2 were made from the same branch.
The proposal, to avoid this issue, is to change the version numbering
scheme to increment the major version for each release branch. We did
not go into too much detail during the discussion, but generally
speaking, so part of the proposal below is me extrapolating in terms
of some of the details while thinking things through a little more --
please feel free to comment and provide other suggestions.
Let's assume that the last release we made had a major version number
of <N> (in our case, <N> is 8):
(a) The next branch would be gdb-<N+1>-branch
(b) Once the branch is cut, we increment the version number on
master to be <N+1>.50.DATE
(b) The first pre-release would be numbered "GDB <N+1>.0.90" [2].
For instance, our next pre-release would be "GDB 9.0.90".
If more pre-releases are needed, we would then increase
the MICRO number, so "GDB 9.0.91", GDB "9.0.92", etc.
Note that additional pre-release are fairly rarely needed
(but have occasionally happened, so we need to be prepared
to generate them).
I'll explain the use of micro numbers after the procedure
is laid out (to avoid clogging the general procedure with
details) [1].
(c) Once the pre-release is out, the version number gets updated
to include the date again, so "<N+1>.0.90.DATE".
(d) The first official release off a release branch would have
the MINOR number set to "1". Thus: "GDB <N+1>.1".
Following that principle, our next major GDB release will be
GDB 9.1.
(e) Once the GDB 9.1 release is made, we switch the branch's version
to "<N+1>.1.90.DATE".
(f) The next official release would be "<N+1>.2".
(g) Once "<N+1>.2" is out, the version number would be set to
"<N+1>.2.90.DATE" again.
(h) Same principle if additional releases are needed ("<N+1>.3", etc).
[1] One property I wanted to have in the procedure above was to have
a consistent minor number for the first official release, so as to
know that GDB <X>.1 is always the first official release from branch
<X>. Combined with the potential need for multiple pre-releases,
and the fact that we want to have increasing version numbers, and
dated version numbers in between, the only way I found was to use
the <X>.0.9X range.
One alternative to using <N+1>.0.90 for pre-release would be to use
<N>.90. It's a shorter version number, and I would be OK with that,
but my sense is that it's kind of confusing that a pre-release
would have a different major version.
[2] Minor note: In the majority of the release cycles, we create the first
pre-release right after the branch is cut. However, there have been
cycles in the past were we wanted to wait for specific fixes before
creating the first pre-release. In those situations, the first
pre-release will be "<N+1>.0.91" instead. I don't think it really
is all that important.
Thoughts? If we agree, I will update gdb/version.in, and look at the
documentation update.
During this year's GNU Cauldron, we discussed the version numbering
scheme the GDB project has been following so far, because a number
of users were confused by it.
At the moment, as you know, GDB's version number is composed of at
least 2 numbers (MAJOR.MINOR) with an optional micro version suffix
(MAJOR.MINOR.MICRO). During each release cycle, we usually increase
the minor number. For instance, since the last release branch was
an 8.2 branch, the next GDB release branch is currently expected to
be 8.3.
The problem with that numbering is that a number of users got confused
by that numbering, thinking that all releases made with the same MAJOR
number were made from the same release branch. So, they thought for
instance that 8.0, 8.1 and 8.2 were made from the same branch.
The proposal, to avoid this issue, is to change the version numbering
scheme to increment the major version for each release branch. We did
not go into too much detail during the discussion, but generally
speaking, so part of the proposal below is me extrapolating in terms
of some of the details while thinking things through a little more --
please feel free to comment and provide other suggestions.
Let's assume that the last release we made had a major version number
of <N> (in our case, <N> is 8):
(a) The next branch would be gdb-<N+1>-branch
(b) Once the branch is cut, we increment the version number on
master to be <N+1>.50.DATE
(b) The first pre-release would be numbered "GDB <N+1>.0.90" [2].
For instance, our next pre-release would be "GDB 9.0.90".
If more pre-releases are needed, we would then increase
the MICRO number, so "GDB 9.0.91", GDB "9.0.92", etc.
Note that additional pre-release are fairly rarely needed
(but have occasionally happened, so we need to be prepared
to generate them).
I'll explain the use of micro numbers after the procedure
is laid out (to avoid clogging the general procedure with
details) [1].
(c) Once the pre-release is out, the version number gets updated
to include the date again, so "<N+1>.0.90.DATE".
(d) The first official release off a release branch would have
the MINOR number set to "1". Thus: "GDB <N+1>.1".
Following that principle, our next major GDB release will be
GDB 9.1.
(e) Once the GDB 9.1 release is made, we switch the branch's version
to "<N+1>.1.90.DATE".
(f) The next official release would be "<N+1>.2".
(g) Once "<N+1>.2" is out, the version number would be set to
"<N+1>.2.90.DATE" again.
(h) Same principle if additional releases are needed ("<N+1>.3", etc).
[1] One property I wanted to have in the procedure above was to have
a consistent minor number for the first official release, so as to
know that GDB <X>.1 is always the first official release from branch
<X>. Combined with the potential need for multiple pre-releases,
and the fact that we want to have increasing version numbers, and
dated version numbers in between, the only way I found was to use
the <X>.0.9X range.
One alternative to using <N+1>.0.90 for pre-release would be to use
<N>.90. It's a shorter version number, and I would be OK with that,
but my sense is that it's kind of confusing that a pre-release
would have a different major version.
[2] Minor note: In the majority of the release cycles, we create the first
pre-release right after the branch is cut. However, there have been
cycles in the past were we wanted to wait for specific fixes before
creating the first pre-release. In those situations, the first
pre-release will be "<N+1>.0.91" instead. I don't think it really
is all that important.
Thoughts? If we agree, I will update gdb/version.in, and look at the
documentation update.
--
Joel
Joel