On Sun, Oct 12, 2008 at 01:41:57AM +0200, Martin Petricek wrote:
> I tried the version manipulation rework (versions-v1.tar.gz from some
> of the later emails)
Please try to keep replies in the same thread, so that we know which
patches are we talking about (even though that we have only one version
of this patch at the moment).
> and there are some thing that should be done
> better:
>
> In part 003_version-consolidation.patch
>
> +
> +// It is not a macro, because we want to provide this information only
> +// during link time to preve
> +/** Version of application.
> ...
> the "preve" word suggest that the sentence should continue. Forgotten?
yep, sorry for that. Something like this should be there:
+// It is not a macro, because we want to provide this information only
+// during link time to prevevent from many modules rebuilding when we
+// change the version string.
I will update the patch. Thanks for poiniting this out.
>
> The revision numbers: unix timestamp is quite long. With SVN you can
> use revision from svn, which is usually about 3 to 5 digit number in
> most projects. There is no such thing in CVS and 10 digits for
> timestamp is perhaps too much for people.
>
> We don't have SVN, so if we need some form of timestamp, I'd prefer
> better format, like YYYYMMDDHHMMSS, for example
Why?
>
> 20081012013209 - longer, but more human-readable and well comparable
> (it is still a number)
We don't need more human-readable. We need something that is *comparable*.
And that doesn't mean only that we are able to compare this number in
the current version string and some other value, but it also means that
we have to get the current number from the source tree. Timestamp is the
easy-to-get value. Whatever more human readable means some more
scripting.
Just think of some some timestamp and what everything you have to do to
try to find such a file in the tree? (I can see very simple solution
when we use timestamps:
print_files | xargs stat -c "%Y" | grep -v -f $EXLUDE_FILES | grep TIMESTAMP
what can be added into getversion - something like -c TIMESTAMP
)
>
> Alternatively generate version with dashes or dots...
>
> 2008-10-12-01-32-09
> 2008.10.12.01.32.09
See comments about parsing and checking above.
>
> I have seen some packages in debian with similar date-based versioning
> for cvs/svn/git versions, but never versioning based on unix
> timestamps.
>
> I have attached modified patch which fixes generating version.xml in
> documentation and fixes docbook2man.pl so it can run from any
> directory
Diff against v1 would help me check all changes much easier. I
understand that CVS doesn't help here much, but quilt would do and it is
not such a big deal:
================================
cd source_tree
quilt import [-p0] 001...
quilt import [-p0] 002...
...
quilt push
[USE YOUR FAVORITE EDITOR AND UPDATE MODIFIED FILES
If you want to add a new file to the patch use:
quilt add file
]
quilt diff -z > changes # Reply to the particular patch with this diff
quilt refresh # Do this after you have done all modification
# because this will rewrite the patch
# same for all patches
===============================
But anyway:
* docbook2man.pl looks good and I have integrated it
- just small update to the makedist and removed FIXME there
* What is the reason for this change? Why would we depend on getversion
script rather than generated version.h?
Index: doc/user/Makefile
===================================================================
RCS file: /cvsroot/pdfedit/pdfedit/doc/user/Makefile,v
retrieving revision 1.28
diff -u -r1.28 Makefile
--- doc/user/Makefile 2 Mar 2008 21:27:40 -0000 1.28
+++ doc/user/Makefile 11 Oct 2008 23:27:56 -0000
@@ -76,8 +76,8 @@
$(TOP_DIR)/tools/leaf2xml.pl <$< >$@ no
# refresh version number
-version.xml: ../../src/gui/version.h
- cd ../.. && ./getversion >doc/user/$@
+version.xml: ../../getversion
+ cd ../.. && ./getversion -v >doc/user/$@
# include rules to generate various documentation formats
include $(TOP_DIR)/Makefile.rules
* typo in getversion integrated.
>
> Martin Petricek
--
Michal Hocko
|