Re: [Libreoffice] [Libreoffice-qa] Naming builds. Please???

On Mon, Dec 05, 2011 at 06:22:33AM -0800, Pedro wrote:


> > There might be more commits in the other repositories in the
> > meantime => the question is what time to use. We might end up with
> > 5 times in the end, e.g.:

> > 41491491-41491527-41491568-41491597-41491613

> > It is quite complex in the end. Also, it would be hard for developers to
> > get the corresponding commit from it.

> That is why I suggested to established a different "birth" date for
> each repository.
> If we established a 2 day interval since TDF's birthday, then you would have

> 414.91491-412.91491-410.91491-408.91491-406.91491

Not, it is still harder than necessary for devs to find what commit
this corresponds to.

> > I see the following needs and solutions:

> >     + easily match about dialog with downloaded tarball

> >       => we need to use the same string in both

> >          I would add one more line with a time generated by configure
> >          to the about dialog. The same time should be used in the
> >          download tarball name

> That would be an easier solution. And human readable.

So the time you want to put is essentially a "build started" date, and
not even that. If an incremental build was done that did not rerun
configure, your date is not updated. We can fix that later point by
instead making that date a .PHONY target in make, but it still does
not satisfy me.

I still prefer my "date of last commit to repo" solution. Yes, we have
five dates instead of one, but that is the truth... If someone builds
with a recent core, but old binfilters, at least it
shows. Essentially, the "last commit" date is a *code* *version*
*number*, that is completely independent of when the build was
done. *That* is what we want.

> >     + easily match build with git commit

> >       => keep the git IDs in about dialog

> My suggestion was to replace the git IDs altogether with the age
> system.

No, the git IDs is the only thing that is easy to use in git. Git IDs
have to stay. Add the dates as an *alternative* for human consumption,
and as a monotonically increasing version number.

-- 
Lionel