[Freeciv-Dev] cvs-tags and snapshots and version number,
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Hello Markus,
> I find term 'latest cvs' ambiguous. We lack way to track
> developement.
---
Abstract :
As the developpement version is stable, I propose to make a release and
increase the patch version number each time a (big enough) patch is
included. I have 2 aims : to know against which version is a patch and to
allow anyone to use the very latest cvs stable version.
---
The version number is composed of 3 numbers :
- major version number,
- minor version number,
- patch version number.
The gnu team though that each time a big enough patch is included in a
project its patch version number has to be increased. 1.8.0 will be
a release version as it is finished by 0. 1.8.12 will be stable version
1.8.0 with 12 patches added. This version will be unstable. Once a patch
has been used and reread for a while, we will have to patch a stable
developpement version named 1.9.0. For example, at the same time, we have
version 1.8.12, we will have version 1.9.10 with 10 bugfree patches. For
me, these are the cvs snapshots you are talking about. They are stable
enough to be used as a basis to create new patches. Also, they are stable
enough to be used at once. Once, we have fullfilled most of the roadmap
for a version, we create a new stable version. The old stable
developpement can still be patches to fix bugs. For example, we do
a release with 1.9.10 called 1.10.0. A version 1.9.11 can be created
later to fix a bug as a bug may have been erased (not fixed) by a patch.
Cvs and the FreeCiv team :
Now, we use the patch version number as the minor version number. As,
thanks to the good work of everyone, the developpement version is stable,
we don't need the unstable developpement branch. Patches are tested
and reread by enough people. We can keep the idea of the stable
developpement branch. I'm not aware of people sending bugs to fix which
were in old versions but not in the current one. So, fix bug branch
seems useless now. The only idea which is left is to increased the patch
version number each time a patch is included in cvs and make a release
with make dist. If we do that, we give a meaning to the patch version
number. The patch version number will appear in any patch which is
against an old cvs version.
Later ... :
What is above is easy to do. If it goes on working fine, it's fine.
If later, bugs are too often found in the developpement version, we will
have to use a unstable developpement branch. If we are asked to correct
a bug in an old version, we will have to add also a bug fix branch for
old version. We will see what is needed.
Nicolas
|
|