HPA suggests it is simply silly to imitate Linux versioning
scheme where the leading "2" does not mean anything anymore, and
I tend to agree.

The first feature release after 1.0.0 will be 1.1.0, and the
development path leading to 1.1.0 will carry 1.0.GIT as the
version number from now on.  Similarly, the third maintenance
release that follows 1.0.0 will not be 1.0.0c as planned, but
will be called 1.0.3.  The "maint" branch will merge in fixes
and immediately tagged, so there is no need for 1.0.2.GIT that
is in between 1.0.2 (aka 1.0.0b) and 1.0.3.

Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Junio C Hamano 2005-12-21 22:33:37 -08:00
Родитель 2a212746f4
Коммит c894168631
2 изменённых файлов: 7 добавлений и 1 удалений

Просмотреть файл

@ -55,7 +55,7 @@ all:
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
GIT_VERSION = 1.0.0.GIT
GIT_VERSION = 1.0.GIT
# CFLAGS and LDFLAGS are for the users to override from the command line.

6
debian/changelog поставляемый
Просмотреть файл

@ -1,3 +1,9 @@
git-core (1.0.GIT-0) unstable; urgency=low
* Post GIT 1.0 development track.
-- Junio C Hamano <junkio@cox.net> Wed, 21 Dec 2005 22:28:33 -0800
git-core (1.0.0.GIT-0) unstable; urgency=low
* Post GIT 1.0.0 development track.