VERSION currently says
1.0.0
I was expecting that to get bumped to 1.0.1 after the release was out so that
we could easily determine that we are running a development version rather
than a release.
But maybe that should be 1.1.0? Or 1.1.1?
devel/hacking.txt says:
We use a variant of three
wafhelpers/options.py contains:
grp.add_option('--build-version-tag', type='string',
help="Append a tag to the version string.")
waf configure prints out things like:
Building version : 0.9.7-e1edbee-hgm
But then n
e...@thyrsus.com said:
> Interesting idea. But I don't see how it solves our problem unless we can
> count on every packager to set this variable. Which ones do?
I think we can do that without help from the packaging environment. We can
put our release date into a git controled file and use
Kurt Roeckx :
> On Mon, Apr 17, 2017 at 06:41:01PM -0700, Hal Murray wrote:
> > I think we can kill two birds with one stone.
> >
> > The first step is to change the code that uses __DATE__ to use the time
> > stamp
> > from autorevision.
>
> Have you seen
> https://reproducible-builds.org/spec
On Mon, Apr 17, 2017 at 06:41:01PM -0700, Hal Murray wrote:
> I think we can kill two birds with one stone.
>
> The first step is to change the code that uses __DATE__ to use the time stamp
> from autorevision.
Have you seen
https://reproducible-builds.org/specs/source-date-epoch/ ?
Kurt
> You are editing files on a system without git and still want fine grain
> versioning? How does that work? How do you know if any files changed?
Mostly, I edit and test on one system, then use scp to push the bits to other
systems. Occasionally, I do a throwaway edit on one of the other sys
Yo Hal!
On Mon, 17 Apr 2017 23:51:34 -0700
Hal Murray wrote:
> >> I want an option that
> >> shows that I've made some edits that aren't committed.
>
> > Just a flag? Maybe waf runs git status and makes a flag from the
> > result?
>
> The option I want needs to run on systems without git.
>> I want an option that
>> shows that I've made some edits that aren't committed.
> Just a flag? Maybe waf runs git status and makes a flag from the result?
The option I want needs to run on systems without git.
I want more than just a flag. I want to know that the result of an edit,
build,
Yo Hal!
On Mon, 17 Apr 2017 21:25:42 -0700
Hal Murray wrote:
> >> So the second step is to add a way to override the time stamp from
> >> autorevision. That will also solve my problem of getting useful
> >> info from the version string.
>
> > Debug mo
>> Maybe git can handle that case. If so, I need a lesson.
> Have you tried git describe?
I don't see how that does what I want.
I'm looking for something that ignores a file and any commits to that file
when I do a push.
.gitignore doesn't do what I want. I need to commit something so I can
Hal Murray :
> >> So the second step is to add a way to override the time stamp from
> >> autorevision. That will also solve my problem of getting useful info
> >> from the version string.
>
> > Debug mode only?
>
> There already is too much tangled
>> So the second step is to add a way to override the time stamp from
>> autorevision. That will also solve my problem of getting useful info
>> from the version string.
> Debug mode only?
There already is too much tangled up with debug.
I've been assuming it would
ime stamp from
> autorevision. That will also solve my problem of getting useful info
> from the version string.
Debug mode only?
> If we don't want to break the build-repro guarantee, we have to put
> the new date into a file or update the last commit date.
commit date is fine.
> S
is only 20 years, so somebody might want to rebuild ntpd to update that.
So the second step is to add a way to override the time stamp from
autorevision. That will also solve my problem of getting useful info from
the version string.
I don't have details of how to do that. My straw man
fallenpega...@gmail.com said:
> While we are at 0.9.*, there isn't a need to distinguish pre-release-under-
> development and "release". Our users so far seem to be quite willing to
> pull from tip, or pull from the most recent tag, depending on what they
> intend. The security researchers look
Hi!
Regarding the version string
While we are at 0.9.*, there isn't a need to distinguish pre-release-under-
development and "release". Our users so far seem to be quite willing to
pull from tip, or pull from the most recent tag, depending on what they
intend. The security rese
hink that means that a big release should be bumping the VERSION string
twice, For example, from 1.5.13 to 1.6.0, then adding the tag, then bumping
it again to 1.7.0
--
These are my opinions. I hate spam.
___
devel mailing list
devel@
17 matches
Mail list logo
