Thread view

I tried the version manipulation rework (versions-v1.tar.gz from some
of the later emails) 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?
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
20081012013209 - longer, but more human-readable and well comparable
(it is still a number)
Alternatively generate version with dashes or dots...
2008-10-12-01-32-09
2008.10.12.01.32.09
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
Martin Petricek

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

>> 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*.
I think it should be even human comparable, since people will see that
number in about box for CVS builds - seeing 20081012013209 will give many
people some idea how old the version is. Seeing 1346860434 won't give them
any clue. The versioning is not only for machines but also for humans,
though we have to be machine-readable too due to various packagers and such
that need to see whether version X is older than Y ...
> 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.
But not much more.
I guess some pseudotimestamp like "20081012.013209" would be still quite
easy to generate and still fully comparable (both by humans and machines) -
newer dates produce numerically bigger numbers. Internally we will work
with timestamp and just before the timestamp is stored in version.h,
convert it to "date"
Just add some filter that will convert timestamp to some another date format.
See http://antonolsen.com/2006/04/06/bash-convert-unix-timestamp-to-a-date/
for some examples
> 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:
Well, I had some trouble running quilt in the past ...
> * What is the reason for this change? Why would we depend on getversion
> script rather than generated version.h?
...
> -version.xml: ../../src/gui/version.h
> - cd ../.. && ./getversion >doc/user/$@
> +version.xml: ../../getversion
> + cd ../.. && ./getversion -v >doc/user/$@
Because in getversion you specify the "PACKAGE_VERSION=0.4.1" - i.e. the
version of the package.
Since ../../src/gui/version.h is generated, it may be still nonexistent or
obsolete when you rebuild documentation sooner than source tree.
Martin Petricek
--
GPG/PGP Public key: http://www.petricek.net/petricm.pgp
Fingerprint 6AA8 FFCE C061 1CB2 55F0 A1F3 3AA9 EB4F BD50 C1B8
/------------------------------------------------------------\
| WWW: http://www.petricek.net/ |
\------------------------------------------------------------/

On Thu, Oct 23, 2008 at 02:03:26AM +0200, Martin Petricek wrote:
> >> 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*.
>
> I think it should be even human comparable, since people will see that
> number in about box for CVS builds - seeing 20081012013209 will give many
> people some idea how old the version is. Seeing 1346860434 won't give them
> any clue. The versioning is not only for machines but also for humans,
> though we have to be machine-readable too due to various packagers and such
> that need to see whether version X is older than Y ...
This is not intended for end users. It is for _us_ to have an idea about
modified sources. Release doesn't provide any measure how old is the
release but how old is the most recently modified file (which is
in the monitored list).
I do expect that 99% of users use release tarballs (CVS statistics show
minimum CVS anon traffic) which contain release only if they are
modified (I expect that less than 1% of our users patch the sources).
>
> > 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.
>
> But not much more.
>
> I guess some pseudotimestamp like "20081012.013209" would be still quite
> easy to generate and still fully comparable (both by humans and machines) -
> newer dates produce numerically bigger numbers. Internally we will work
> with timestamp and just before the timestamp is stored in version.h,
> convert it to "date"
I am not arguing that date format is bad or hard to generate/compare. I
just don't see a point to do it. Nevertheless (to make this discussion
shorter) I will update patchset to use
date --date=@TIMESTAMP -u +%Y%m%d%H%M%S
>
> Just add some filter that will convert timestamp to some another date format.
> See http://antonolsen.com/2006/04/06/bash-convert-unix-timestamp-to-a-date/
> for some examples
>
> > 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:
>
> Well, I had some trouble running quilt in the past ...
>
> > * What is the reason for this change? Why would we depend on getversion
> > script rather than generated version.h?
version.h is not generated. Sorry for confusion.
> ...
> > -version.xml: ../../src/gui/version.h
> > - cd ../.. && ./getversion >doc/user/$@
> > +version.xml: ../../getversion
> > + cd ../.. && ./getversion -v >doc/user/$@
>
> Because in getversion you specify the "PACKAGE_VERSION=0.4.1" - i.e. the
> version of the package.
> Since ../../src/gui/version.h is generated, it may be still nonexistent or
> obsolete when you rebuild documentation sooner than source tree.
When thinking about this again, it doesn't make sense to depend on
what-ever version.{cc,h} at all. We don't get any piece of information
from there. getversion is self-contained.
So the dependency is useless but good point in -v parameter which I have
missed.
I will update respective patch with:
Index: pdfedit-patches/doc/user/Makefile
===================================================================
--- pdfedit-patches.orig/doc/user/Makefile 2008-10-23 11:42:45.000000000 +0200
+++ pdfedit-patches/doc/user/Makefile 2008-10-23 11:56:41.000000000 +0200
@@ -76,8 +76,8 @@ scripts/qsa-util.xml: qsa-util.leaf $(TO
$(TOP_DIR)/tools/leaf2xml.pl <$< >$@ no
# refresh version number
-version.xml: ../../src/gui/version.h
- cd ../.. && ./getversion >doc/user/$@
+version.xml:
+ cd ../.. && ./getversion -v >doc/user/$@
# include rules to generate various documentation formats
include $(TOP_DIR)/Makefile.rules
Thanks for noticing.
>
> Martin Petricek
>
> --
>
>
> GPG/PGP Public key: http://www.petricek.net/petricm.pgp
> Fingerprint 6AA8 FFCE C061 1CB2 55F0 A1F3 3AA9 EB4F BD50 C1B8
> /------------------------------------------------------------\
> | WWW: http://www.petricek.net/ |
> \------------------------------------------------------------/
Are there any other issues or I can go on and commit it to the CVS?
--
Michal Hocko

> This is not intended for end users. It is for _us_ to have an idea about
For us. For humans :)
> shorter) I will update patchset to use
> date --date=@TIMESTAMP -u +%Y%m%d%H%M%S
OK, good solution.
> from there. getversion is self-contained.
getversion contains the version anbd it is set there, i.e. now it contains
0.4.1
> So the dependency is useless but good point in -v parameter which I have
> missed.
> I will update respective patch with:
> Index: pdfedit-patches/doc/user/Makefile
> ===================================================================
> --- pdfedit-patches.orig/doc/user/Makefile 2008-10-23 11:42:45.000000000 +0200
> +++ pdfedit-patches/doc/user/Makefile 2008-10-23 11:56:41.000000000 +0200
> @@ -76,8 +76,8 @@ scripts/qsa-util.xml: qsa-util.leaf $(TO
> $(TOP_DIR)/tools/leaf2xml.pl <$< >$@ no
>
> # refresh version number
> -version.xml: ../../src/gui/version.h
> - cd ../.. && ./getversion >doc/user/$@
> +version.xml:
> + cd ../.. && ./getversion -v >doc/user/$@
But then if the getversion script gets changed (i.e. the version gets
bumped), version.xml won't get regenerated. Mostly not an issue, unless you
generate documentation directly from checkout (for putting on web for
example), that have been upgraded to newer version in the meantime. I don't
think dependency here is useless.
Martin Petricek
> Are there any other issues or I can go on and commit it to the CVS?
You can commit it, but perhaps you should re-add dependency for version.xml
on getversion script ....
--
GPG/PGP Public key: http://www.petricek.net/petricm.pgp
Fingerprint 6AA8 FFCE C061 1CB2 55F0 A1F3 3AA9 EB4F BD50 C1B8
/------------------------------------------------------------\
| WWW: http://www.petricek.net/ |
\------------------------------------------------------------/

> No. This rule says that getversion is run everytime (no dependency) so
OK, I misunderstood makefile rules, then your solution os better of course :)
> Please have a look at the patch in this email and I will commit it then.
Add the patch from the email and commit it to CVS
Martin Petricek
--
GPG/PGP Public key: http://www.petricek.net/petricm.pgp
Fingerprint 6AA8 FFCE C061 1CB2 55F0 A1F3 3AA9 EB4F BD50 C1B8
/------------------------------------------------------------\
| WWW: http://www.petricek.net/ |
\------------------------------------------------------------/