>>>>> "David" == David Kastrup <[EMAIL PROTECTED]> writes:
David> Jan-Åke Larsson <[EMAIL PROTECTED]> writes:
>> David Kastrup wrote:
>>> a) take the version string from autoconf.
>>
>> This is the usual way to do it.
>>
>>> e) Just go by the last ChangeLog entry (releases have special syntax
>>> and can be discerned).
>>
>> Since we have quite a few CVS users, I can see the need for doing it
>> this way.
>>
>>> d) use the release number if a regularly exported release, use the
>>> topmost date in the ChangeLog file if not.
>>
>> This is probably the sanest alternative. Now, ISTR Uwe is using his
>> own CVS repository for XEmacs packaging, correct? This has to be
>> robust so that we won't get confusing bug reports, for Uwe's XEmacs
>> packages.
David> I see no problem here. You have to export using a particular release
David> tag in order to get the release string, and I doubt that XEmacs
David> developers do that with a release version string compatible to ours.
David> I also have been unable to persuade Uwe to use the "cvs admin -kb"
David> option on tex.el so that their CVS does not tamper with our version
David> numbers, so I think that this will likely continue when we move the
David> version $Name: $ string into auctex.el.
Just for the records. I tried that I tried in fact all your proposals,
but it did *not* work, I was forced to insert that string manually.
David> So the version would revert to the ChangeLog date always
David> and never to an upstream release number. Which is probably
David> not the worst idea.
David> Given the recent fallout on the XEmacs beta development
David> lists where it was quite categorically stated that if we
David> provided completely finished packages for XEmacs ourselves,
David> they would not get used anyway, it might be an idea, once
David> that the build process is valid for the whole AUCTeX
David> package, to provide XEmacs packages of our own and ask the
David> XEmacs maintainers to change the bug reporting address of
David> their own variant.
Which most likely would lead to result, that 'real auctex' bugs would
then be redirected to the auctex list, but anyhow, this is your decision.
David> I don't really fancy dealing with bug reports for a version
David> for which we are considered irresponsible.
David> --
David> David Kastrup, Kriemhildstr. 15, 44793 Bochum
David> _______________________________________________
David> auctex-devel mailing list
David> [email protected]
David> http://lists.gnu.org/mailman/listinfo/auctex-devel
_______________________________________________
auctex-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/auctex-devel
