Hi, Karl would like me to remove \luatexdatestamp (and its associated lua value), because that makes it easier to create new binaries from the same source code (without getting small differences always). That is a good argument, so my current plan is to remove it in the next version. Consider yourself warned ;) Best wishes, Taco
On Tue, Oct 1, 2013 at 10:26 AM, Taco Hoekwater wrote:
Hi,
Karl would like me to remove \luatexdatestamp (and its associated lua value), because that makes it easier to create new binaries from the same source code (without getting small differences always).
That is a good argument, so my current plan is to remove it in the next version. Consider yourself warned ;)
Thank you. I also asked a couple of times to at least replace this date with the date of the latest change in SVN. The latter would be at least consistent and informative, while the date of compilation is both unreliable and causes constant change of the binaries. I believe this is also less of an issue now that LuaTeX is more or less stable and the LuaTeX version is mostly sufficient. In past when everyone was using "the latest" version from trunk it was more important to know which version it was. Mojca
On 10/1/2013 10:33 AM, Mojca Miklavec wrote:
On Tue, Oct 1, 2013 at 10:26 AM, Taco Hoekwater wrote:
Hi,
Karl would like me to remove \luatexdatestamp (and its associated lua value), because that makes it easier to create new binaries from the same source code (without getting small differences always).
That is a good argument, so my current plan is to remove it in the next version. Consider yourself warned ;)
Thank you. I also asked a couple of times to at least replace this date with the date of the latest change in SVN. The latter would be at least consistent and informative, while the date of compilation is both unreliable and causes constant change of the binaries.
I believe this is also less of an issue now that LuaTeX is more or less stable and the LuaTeX version is mostly sufficient. In past when everyone was using "the latest" version from trunk it was more important to know which version it was.
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go away Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 10/01/2013 11:11 AM, Hans Hagen wrote:
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go awa
Does it matter to you whether it is an actual date string, or could it be a subversion revision number? (both are possible, the date string would simply switch to the datetime associated with the subversion revision instead of the actual build date). Taco
On 10/1/2013 11:19 AM, Taco Hoekwater wrote:
On 10/01/2013 11:11 AM, Hans Hagen wrote:
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go awa
Does it matter to you whether it is an actual date string, or could it be a subversion revision number? (both are possible, the date string would simply switch to the datetime associated with the subversion revision instead of the actual build date).
anything that distinguishes is fine although when developing, i guess that not all iterations go into svn so we need to figure out a way ... for production it's less important but i remember that we introduced the date because in a extensive dev cycle it is really convenient maybe there is a way to distinguish a release from a branch and use only dates for branches; it would also mean that when we have a release, that there will not be patches and fixes without bumping the number (or else we get support hell) as we did in the past Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 10/1/2013 11:19 AM, Taco Hoekwater wrote:
On 10/01/2013 11:11 AM, Hans Hagen wrote:
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go awa
Does it matter to you whether it is an actual date string, or could it be a subversion revision number? (both are possible, the date string would simply switch to the datetime associated with the subversion revision instead of the actual build date).
(to be clear: i don't use the primitive, just the banner, so the primitive can go anyway) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 10/1/2013 11:26 AM, Hans Hagen wrote:
On 10/1/2013 11:19 AM, Taco Hoekwater wrote:
On 10/01/2013 11:11 AM, Hans Hagen wrote:
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go awa
Does it matter to you whether it is an actual date string, or could it be a subversion revision number? (both are possible, the date string would simply switch to the datetime associated with the subversion revision instead of the actual build date).
(to be clear: i don't use the primitive, just the banner, so the primitive can go anyway)
we could have luatex 0.77.0 (rev xxxx) (date ....) (beta- prefix not needed) and any piece of the workflow could ignore whatever bit they like and/or the date part could be omitted for stable releases ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Tue, Oct 1, 2013 at 11:41 AM, Hans Hagen
On 10/1/2013 11:26 AM, Hans Hagen wrote:
On 10/1/2013 11:19 AM, Taco Hoekwater wrote:
On 10/01/2013 11:11 AM, Hans Hagen wrote:
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go awa
Does it matter to you whether it is an actual date string, or could it be a subversion revision number? (both are possible, the date string would simply switch to the datetime associated with the subversion revision instead of the actual build date).
(to be clear: i don't use the primitive, just the banner, so the primitive can go anyway)
we could have
luatex 0.77.0 (rev xxxx) (date ....)
(beta- prefix not needed)
and any piece of the workflow could ignore whatever bit they like and/or the date part could be omitted for stable releases
+1
I understand the problem of triggering useless compilation due the change in the date only, but I think that it's easily solvable by an adequate parse of the banner that saves only the components needed. -- luigi
On Tue, Oct 1, 2013 at 12:23 PM, luigi scarso wrote:
I understand the problem of triggering useless compilation due the change in the date only, but I think that it's easily solvable by an adequate parse of the banner that saves only the components needed.
Can you please explain? (I'm not sure if what I understood is what you were trying to say.) Mojca
On 10/1/2013 11:11 AM, Hans Hagen wrote:
as long as we keep the (unique) date in the luatex banner ... context uses that for automatically regenerating the format etc and that's a feature I'd not like to see go away
(we had rev. xxxx once so when date goes, that one has to come back to identify at least a difference) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Hans Hagen -
luigi scarso -
Mojca Miklavec -
Taco Hoekwater