Versioning scheme changes.

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>

diff --git a/Makefile b/Makefile
index 782cff9d5dade1d44e675e324455bfb52e4d9091..88b89f956fc46e2e2b417efee654b48d7b12768f 100644 (file)
--- a/Makefile
+++ b/Makefile
@@ -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.
 

diff --git a/debian/changelog b/debian/changelog
index 491ebd9ba2fe47c7d6d904a4b50ed9b0a8c202a0..084e37a37ad42138866dda7c14816702745c5bd8 100644 (file)
--- a/debian/changelog
+++ b/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.