9:02 p.m.
Hello
Auctex 11.88 is out a couple of weeks ago containing significant
improvements and this time I want to synchronise it as soon as possible.
We had the discussion concerning the numeration scheme of our packages a
couple of times (without coming to an agreement).
But can I, just for Auctex, switch to a more debian like scheme???
I would call the new release
auctex-11.88-pkg.tar.gz
And changes which would be made from our side, but not by the Auctex
team:
11.88-a, 11.88-b
Or 11.88-I or whatsoever.
Rationale: it would the user allow to immediately recognise to which
official auctex version the official xemacs pkg would correspond.
Any objections to this?
regards
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:30 p.m.
* Uwe Brauer <oub(a)mat.ucm.es>:
Hi!
And changes which would be made from our side, but not by the Auctex
team:
11.88-a, 11.88-b
Or 11.88-I or whatsoever.
Rationale: it would the user allow to immediately recognise to which
official auctex version the official xemacs pkg would correspond.
Any objections to this?
This would require a change to the package creation (and numbering)
process which at the moment simply increases the numbers.
Everything is doable, but do you really think, the number of changes is
that high? You have the AUTHOR version which you could set to the 11.88
in order to give users a hint what official release they're working
with.
norbert.
--
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:08 p.m.
Uwe Brauer writes:
But can I, just for Auctex, switch to a more debian like scheme???
No, AFAIK, not possible without "fixing" the package management
libraries. They don't recognize anything but the xx.yy format.
Presumably changing this would involve patches to 21.4, 21.5, and
SXEmacs.
I would call the new release
auctex-11.88-pkg.tar.gz
This is fine. VM already does this. But VM has historically been
willing to cooperate with XEmacs needs (ie, a new release with XEmacs
changes in it). I doubt AUCTeX would.
And changes which would be made from our side, but not by the Auctex
team:
11.88-a, 11.88-b
Or 11.88-I or whatsoever.
This is problematic. I don't think the package functions can handle
this at all currently.
The problem with patches to enable this is where do you stop? The
Debian scheme is gross because it tries to cater to pretty much any
upstream versioning system. For example, what if AUCTeX brown-bags
the release and decides to release 11.88-a itself? Debian's scheme
can handle that. Or if they decide to change to a 3-part scheme and
start over at 1.0.0? Debian can handle that, too.
Python has come up with official versioning guidelines (reasonably
flexible but not insanely so). But they can do that because they are
in control of their package distribution network (PyPI) and have a lot
of power over upstream packages for that reason. That's not true of
XEmacs.
Rationale: it would the user allow to immediately recognise to
which official auctex version the official xemacs pkg would
correspond.
That information is already available in M-x list-packages, i command.
I think it's preferable to improve the informational functionality of
list-packages (perhaps show upstream versions by default, and XEmacs
package versions only on demand), which would also provide the same
benefit to other packages.
I think your best solution is use auctex-11.88-pkg.tar.gz and hope you
never need the modifiers. Although I don't know what happens after
AUCTeX v11.99, which doesn't seem that far off.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:44 p.m.
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> But can I, just for Auctex, switch to a more debian like scheme???
No, AFAIK, not possible without "fixing" the package
management
libraries. They don't recognize anything but the xx.yy format.
Presumably changing this would involve patches to 21.4, 21.5, and
SXEmacs.
> I would call the new release
> auctex-11.88-pkg.tar.gz
This is fine. VM already does this.
I did some testing:
I just modified in the
Makefile of the auctex (still not upgraded to 11.88) directory the relevant string
VERSION = 11.84
I even tried
VERSION = 11.84-b
And make bindist
did generate
auctex-11.84-pkg.tar.gz
auctex-11.84-b-pkg.tar.gz
Respectively.
Will that cause any problem for Norbert?
But VM has historically been
willing to cooperate with XEmacs needs (ie, a new release with XEmacs
changes in it). I doubt AUCTeX would.
Two comments:
- the version I want to release is not strictly 11.88, but with a
little patch, thanks to Mosè which made a variable backward
compatible. According to the Auctex folks, that is also true for
elpa, the current version is not *exactly* 11.88.
- if we found a functionality in auctex which would need some
modifications wrapped with a (with (featurep 'xemacs) I am pretty
sure the auctex team would accept it. Now I had a look the
Changelog[1] since 11.84 the changes done, would not affect
functionality provided by auctex so I doubt it would go in their
package.
However if I change now the scheme to 11.88 and we would make some
(internal) changes I would not like to call the new release 11.89, if
11.88-a is not possible I would even propose not to change the release
number at all.
> And changes which would be made from our side, but not by the
Auctex
> team:
>
> 11.88-a, 11.88-b
>
> Or 11.88-I or whatsoever.
This is problematic. I don't think the package functions can
handle
this at all currently.
As I said above I just changed the string and make bindist worked in the
auctex directory and also in the main directory.
I am puzzled.
Uwe
Footnotes:
[1] there is something odd, it seems some information got lost when
moving from CVS to mercury, because I remember the problems with
11.84 and the contribution of Mats, and this was around 2008/2009
but it is not reflected in the Changelog, it seems that the
upgrade to 11.84 is from 2014 which is wrong
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:33 a.m.
>>>> Uwe Brauer <oub(a)mat.ucm.es> writes:
However if I change now the scheme to 11.88 and we would make some
(internal) changes I would not like to call the new release 11.89,
if 11.88-a is not possible I would even propose not to change the
release number at all.
That is why it is good to stick with the old number scheme. It is true
you need to know what xemacs package version matches what upstream
version but that is a feature! (IMHO)
Besides having different numbering schemes will, I think, make my job
of maintaining for Gentoo a little bit harder.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:42 a.m.
Uwe Brauer writes:
I did some testing:
I just modified in the
Makefile of the auctex (still not upgraded to 11.88) directory the relevant string
This test is irrelevant. I'm not surprised that the Makefile handles
this and generates the expected tarfiles. Make is basically a macro
language and doesn't care what you put in variables.
What matters is the behavior of list-packages and pkg-admin.el and
friends.
- the version I want to release is not strictly 11.88, but with
a
little patch, thanks to Mosè which made a variable backward
compatible. According to the Auctex folks, that is also true for
elpa, the current version is not *exactly* 11.88.
Already worrisome. If they don't care about ELPA, then I suppose
they'll let XEmacs slide too.
- if we found a functionality in auctex which would need some
modifications wrapped with a (with (featurep 'xemacs) I am pretty
sure the auctex team would accept it. Now I had a look the
Changelog[1] since 11.84 the changes done, would not affect
functionality provided by auctex so I doubt it would go in their
package.
(1) It's not a question of whether they would accept XEmacs-related
changes. The question is whether they would bump the release
number just because *we* need a new release.
(2) Specifically, does AUCTeX distribute the XEmacs package Makefile?
Many XEmacs-specific changes are changes to that file. We need to
distinguish versions so users know what they're getting. But if
they don't distribute that file, I hardly think they'll be happy
bumping the version so that we can change the file and release a
new version.
However if I change now the scheme to 11.88 and we would make some
(internal) changes I would not like to call the new release 11.89, if
11.88-a is not possible I would even propose not to change the release
number at all.
I don't think that proposal is acceptable. Users who already have
version 11.88 will have no way to know they need to upgrade. To do
the upgrade I suspect they will need to remove and reinstall.
[1] there is something odd, it seems some information got lost when
moving from CVS to mercury, because I remember the problems with
11.84 and the contribution of Mats, and this was around 2008/2009
but it is not reflected in the Changelog, it seems that the
upgrade to 11.84 is from 2014 which is wrong
No, that's correct. In fact the upgrade *did* happen in 2014 because
the 11.84 stuff was off on a branch in CVS and never merged to
mainline that I remember. That situation was continued in Mercurial
(I don't recall whether the branch got replicated in Mercurial or we
had to reimport it.) Then more XEmacs-specific work got done on top
of 11.55 (IIRC), so it was a small mess.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:06 a.m.
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> I did some testing: I just modified in the Makefile of the auctex
> (still not upgraded to 11.88) directory the relevant string
This test is irrelevant. I'm not surprised that the Makefile
handles
this and generates the expected tarfiles. Make is basically a macro
language and doesn't care what you put in variables.
What matters is the behavior of list-packages and pkg-admin.el and
friends.
How could I test this?
> - the version I want to release is not strictly 11.88, but with
a
> little patch, thanks to Mosè which made a variable backward
> compatible. According to the Auctex folks, that is also true for
> elpa, the current version is not *exactly* 11.88.
Already worrisome. If they don't care about ELPA, then I
suppose
they'll let XEmacs slide too.
I am no sure what you mean by «slide». Despite the fact that
there are no XEmacs users among their main contributers, they
still care about XEmacs compatibility. Well at least if it
concerns a bug. If it concerns a missing feature, than maybe not,
but of course they are not to be blamed.
The auctex team does not release very often, but when it does, the «leap
forward» is notable. Most likely that strategy is what them fits best.
Currently they are only two main developers, David and Ralf are «there»
but don't really contribute with code. (Auctex is also a extreme mature
piece of software)
I hang around with some beta testing, but despite some style file
contribution a long time ago, I don't contribute any code
> - if we found a functionality in auctex which would need some
> modifications wrapped with a (with (featurep 'xemacs) I am pretty
> sure the auctex team would accept it. Now I had a look the
> Changelog[1] since 11.84 the changes done, would not affect
> functionality provided by auctex so I doubt it would go in their
> package.
(1) It's not a question of whether they would accept
XEmacs-related
changes. The question is whether they would bump the release
number just because *we* need a new release.
(2) Specifically, does AUCTeX distribute the XEmacs package
Makefile?
Many XEmacs-specific changes are changes to that file. We need to
distinguish versions so users know what they're getting. But if
they don't distribute that file, I hardly think they'll be happy
bumping the version so that we can change the file and release a
new version.
They don't. They have their own Makefile which even generates their own
version of our pkg, which lives happily in ~/.xemacs/xemacs-packages
https://www.gnu.org/software/auctex/download-for-unix.html
> However if I change now the scheme to 11.88 and we would make
some
> (internal) changes I would not like to call the new release 11.89, if
> 11.88-a is not possible I would even propose not to change the release
> number at all.
I don't think that proposal is acceptable. Users who already
have
version 11.88 will have no way to know they need to upgrade. To do
the upgrade I suspect they will need to remove and reinstall.
I agree: in an ideal world (say some 10 years ago) you are right. But
let me try at least once to convince you.[1]
Lets be realistic here: The traffic in Xemacs beta is far inferior too
the one in GNU Emacs devel, indicating a much smaller user base. Worse:
most likely the Auctex user base is even smaller. I don't recall any
auctex specific subject in the last 5 years [2]. Additionally a
typical Auctex user would be interested in an upgrade if:
- new exciting features are included, which basically means a new
release from the auctex team.
- a Xemacs specific bug has been solved, in which case as I said
the auctex team would care and might release a new version.
However the changes we made this year, which are reflected in
the ChangeLog, are
- .hgignore: Ignore .elcs in etc.
- doc/auctex.texi (Font Specifiers): Texinfo 5.2 fixes.
- preview/latex/preview.dtx: Expand CVS keywords manually.
In my judgement only the texinfo fix might be relevant to the average
user, while the fixes might not. So frankly I don't think the typical
user (out of a very small set of users) would loose anything when not
upgrading.
> [1] there is something odd, it seems some information got lost
when
> moving from CVS to mercury, because I remember the problems with
> 11.84 and the contribution of Mats, and this was around 2008/2009
> but it is not reflected in the Changelog, it seems that the
> upgrade to 11.84 is from 2014 which is wrong
No, that's correct. In fact the upgrade *did* happen in 2014
because
the 11.84 stuff was off on a branch in CVS and never merged to
mainline that I remember. That situation was continued in Mercurial
(I don't recall whether the branch got replicated in Mercurial or we
had to reimport it.) Then more XEmacs-specific work got done on top
of 11.55 (IIRC), so it was a small mess.
Uff, that is worse than I thought. So all the work Mats (mostly)
and I did for the upgrade was not reflected till this year.
To conclude:
- please consider that our internal changes would not result
in a release with a new release number.
- how can we test the notation 11.88-a would work?
- if none of the above is acceptable or works, than I would stick
to the old system, since the danger of having our 11.89 release which
does not correspond to the 11.89 release of auctex does not look
acceptable to me.
regards
Uwe
Footnotes:
[1] without hopefully running into a flamewar
[2] I had recently a discussion with some Xemacs auctex user on a
german TeX list and he also mentioned his grandchildren.....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:27 p.m.
Uwe Brauer writes:
How could I test [behavior of package tools]?
Create a directory with packages in it and point
package-get-download-sites at it.
> Already worrisome. If they don't care about ELPA, then I
suppose
> they'll let XEmacs slide too.
I am no sure what you mean by «slide».
Don't worry about it. On second thought it doesn't matter AUCTeX
thinks about it.
I agree: in an ideal world (say some 10 years ago) you are right.
But
let me try at least once to convince you.[1]
Doing it right will be a lot of work.
In my judgement only the texinfo fix might be relevant to the
average
user, while the fixes might not. So frankly I don't think the typical
user (out of a very small set of users) would loose anything when not
upgrading.
That's not the point; the point is that if you switch to AUCTeX
versioning, and then do make an important change between AUCTeX
releases, it *will* be invisible to existing users. They'll have to
find out about it for themselves, then download and install by hand.
To conclude:
- please consider that our internal changes would not result
in a release with a new release number.
It's your package, you can do what you want as long Norbert is OK with
it. I think that's a very bad idea, and it's not reliable --
eventually there will be an important reason to do a release out of
sync with upstream.
- how can we test the notation 11.88-a would work?
Somebody did already, and it doesn't.
- if none of the above is acceptable or works, than I would
stick to the old system,
This is by far the best option at the moment.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:36 p.m.
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
That's not the point; the point is that if you switch to AUCTeX
versioning, and then do make an important change between AUCTeX
releases, it *will* be invisible to existing users. They'll have to
find out about it for themselves, then download and install by hand.
I don't agree completely since important changes had a high change of be
included in auctex official. But I don't want to break with a practise
which is well established for decades especially if you don't agree.
> - how can we test the notation 11.88-a would work?
Somebody did already, and it doesn't.
Oh, who and when???? Now I am curious.
> - if none of the above is acceptable or works, than I would
> stick to the old system,
This is by far the best option at the moment.
Well it seems that the disadvantage of changing the numbering scheme
does not out weights its benefits.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:28 p.m.
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Uwe Brauer writes:
> - how can we test the notation 11.88-a would work?
Somebody did already, and it doesn't.
Again: who tested it and what went wrong?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3418
days inactive
3427
days old
9 comments
4 participants
participants (4)
-
Norbert Koch -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer