[Practicalxml-commits] SF.net SVN: practicalxml:[138] trunk/README.txt

[Auto-Generated S. C. M. <pra...@li...>]

Revision: 138
          http://practicalxml.svn.sourceforge.net/practicalxml/?rev=138&view=rev
Author:   kdgregory
Date:     2009-09-17 12:49:44 +0000 (Thu, 17 Sep 2009)

Log Message:
-----------
add more explanation about release numbering

Modified Paths:
--------------
    trunk/README.txt

Modified: trunk/README.txt
===================================================================
--- trunk/README.txt	2009-09-16 22:10:04 UTC (rev 137)
+++ trunk/README.txt	2009-09-17 12:49:44 UTC (rev 138)
@@ -31,18 +31,37 @@
               repository. Minor releases preserve backwards compatibility:
               code written for one minor release will work when linked
               with another minor release.
-        PATCH releases won't actually get released: the PATCH revision
-              number should be incremented with each checkin, in preference
-              to using a "-SNAPSHOT" of the next minor release. This will
-              lock users into keeping their build scripts and local repository
-              up-to-date, which is a Good Thing.
+        PATCH releases happen whenever a method or class gets added or
+              changed in a minor way. They will not be released to any
+              central repository, and will probably not be tagged either.
 
     Major and minor releases will be tagged in the Subversion repository,
     using the form "rel-X.Y", where X and Y are the major and minor release
     numbers. Patch releases may be tagged using the form "rel-X.Y.Z", if the
     maintainer decides that it's important to rebuild that particular release
-    (although making it a minor release might be a better idea).
+    (eg, as a dependency for another application).
 
     Major and minor releases will be available for download from Sourceforge
     ( http://sourceforge.net/project/showfiles.php?group_id=234884 ), and also
     from the Central Maven Repository.
+
+    The whole "patch release" idea has caused some controversy. My thought with
+    these releases is that they're a step above "nightly development build,"
+    and represent stable functionality. By giving fixed release numbers, your
+    build tool should call out any possible incompatibilities, such as "your
+    main project relies on 1.0.15, but your repository contains 1.0.17, why?"
+    I believe that long-lived "snapshot" builds on the trunk are a bad idea
+    (that said, if you're making a number of changes and want to check-in
+    increments, feel free to put "SNAPSHOT" on the revision number; but try
+    to finish within a day).
+
+    As far as tagging goes, I don't think that it's necessary unless you rely
+    on a particular patch revision. Then go for it. Since Subversion revision
+    numbers apply to the entire repository, you can always create an tag for
+    some past point in time. Easiest way to do this is browse the history of
+    pom.xml.
+
+    To clear up one last bit of confusion: the patch number should only be
+    incremented when the external API has changed. If you add comments, or
+    tests, or even completely rewrite the internals, the patch number stays
+    the same. 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.