* bug#10838: 24.0.92; package.el shows a misleading version number
@ 2012-02-17 18:40 Phil Hagelberg
2012-02-17 23:46 ` Stefan Monnier
2012-02-25 4:56 ` Chong Yidong
0 siblings, 2 replies; 11+ messages in thread
From: Phil Hagelberg @ 2012-02-17 18:40 UTC (permalink / raw)
To: 10838
I'm passing on this bug report from the repository where I was
maintaining package.el in preparation for merging it into Emacs itself:
https://github.com/technomancy/package.el/issues/5
> There is a version of package.el which is available from
> tromey.com/elpa, which is clearly the starting point for this
> package.el, which claims to be version 0.9 in the head of the file. The
> current (and emacs23) versions contain this same version number, despite
> having significantly different features. This is misleading and
> remarkably confusing. The version numbers in both the emacs24 and
> emacs23 versions should be updated to indicate that they contain new
> features.
I agree that incrementing the version number makes sense as a lot of
features have been added since the 0.9 release.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-17 18:40 bug#10838: 24.0.92; package.el shows a misleading version number Phil Hagelberg
@ 2012-02-17 23:46 ` Stefan Monnier
2012-02-18 0:01 ` Phil Hagelberg
2012-02-25 4:56 ` Chong Yidong
1 sibling, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2012-02-17 23:46 UTC (permalink / raw)
To: Phil Hagelberg; +Cc: 10838
> I agree that incrementing the version number makes sense as a lot of
> features have been added since the 0.9 release.
IIUC the package.el we distribute is not synchronized with the unbundled
package.el any more, right? So it doesn't need a version number any
more (it's version number is the one of Emacs).
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-17 23:46 ` Stefan Monnier
@ 2012-02-18 0:01 ` Phil Hagelberg
2012-02-18 22:40 ` Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: Phil Hagelberg @ 2012-02-18 0:01 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10838
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> IIUC the package.el we distribute is not synchronized with the unbundled
> package.el any more, right? So it doesn't need a version number any
> more (it's version number is the one of Emacs).
If we want to backport package.el to work in Emacs 23 then we should
probably keep the version number, but if we decide that's not worth it
then it could be dropped. I haven't looked into what's keeping it from
working on 23; I've just been pointing 23 users at an older version.
Would you like me to investigate to see how much it would take to make
it work?
-Phil
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-18 0:01 ` Phil Hagelberg
@ 2012-02-18 22:40 ` Stefan Monnier
2012-02-25 5:23 ` Phil Hagelberg
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2012-02-18 22:40 UTC (permalink / raw)
To: Phil Hagelberg; +Cc: 10838
>> IIUC the package.el we distribute is not synchronized with the unbundled
>> package.el any more, right? So it doesn't need a version number any
>> more (it's version number is the one of Emacs).
> If we want to backport package.el to work in Emacs 23 then we should
> probably keep the version number,
I don't think so: if the canonical package.el is the one that comes with
Emacs, then it's version number is Emacs's (i.e. there "package.el from
Emacs-24.1" and "package.el from Emacs-24.2, ...").
> but if we decide that's not worth it then it could be
> dropped. I haven't looked into what's keeping it from working on 23;
> I've just been pointing 23 users at an older version. Would you like
> me to investigate to see how much it would take to make it work?
I haven't thought about this. It'd be good to have a package.el that
works with Emacs-23 to access GNU ELPA, but it doesn't have to be sync'd
with Emacs-24's. So unless package.el version 0.9 has problems
accessing GNU ELPA, I see no need to backport the current code.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-17 18:40 bug#10838: 24.0.92; package.el shows a misleading version number Phil Hagelberg
2012-02-17 23:46 ` Stefan Monnier
@ 2012-02-25 4:56 ` Chong Yidong
2012-02-25 5:23 ` Phil Hagelberg
2012-03-01 16:49 ` Tom Tromey
1 sibling, 2 replies; 11+ messages in thread
From: Chong Yidong @ 2012-02-25 4:56 UTC (permalink / raw)
To: Tom Tromey; +Cc: 10838, Phil Hagelberg
> There is a version of package.el which is available from
> tromey.com/elpa, which is clearly the starting point for this
> package.el, which claims to be version 0.9 in the head of the file. The
> current (and emacs23) versions contain this same version number, despite
> having significantly different features. This is misleading and
> remarkably confusing. The version numbers in both the emacs24 and
> emacs23 versions should be updated to indicate that they contain new
> features.
IMO, it's desireable for the package.el in Emacs to retain a version
number header, just in case there is any package that in turn relies on
package.el (even though sounds pretty theoretical). I propose bumping
the package.el in Emacs to 1.0. Any objection?
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-18 22:40 ` Stefan Monnier
@ 2012-02-25 5:23 ` Phil Hagelberg
2012-02-25 9:46 ` Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: Phil Hagelberg @ 2012-02-25 5:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10838
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> but if we decide that's not worth it then it could be
>> dropped. I haven't looked into what's keeping it from working on 23;
>> I've just been pointing 23 users at an older version. Would you like
>> me to investigate to see how much it would take to make it work?
>
> I haven't thought about this. It'd be good to have a package.el that
> works with Emacs-23 to access GNU ELPA, but it doesn't have to be sync'd
> with Emacs-24's. So unless package.el version 0.9 has problems
> accessing GNU ELPA, I see no need to backport the current code.
The problem is there are many versions claiming to be 0.9. The original
one on tromey.com (which did not support multiple sources) probably has
the best claim of being "the real 0.9". I think Chong's suggestion of
releasing 24 with package.el 1.0 makes sense, and if we decide to
backport a few changes for official 23-compatibility it could be 0.9.1
or something.
-Phil
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-25 4:56 ` Chong Yidong
@ 2012-02-25 5:23 ` Phil Hagelberg
2012-03-01 16:49 ` Tom Tromey
1 sibling, 0 replies; 11+ messages in thread
From: Phil Hagelberg @ 2012-02-25 5:23 UTC (permalink / raw)
To: Chong Yidong; +Cc: Tom Tromey, 10838
On Fri, Feb 24, 2012 at 8:56 PM, Chong Yidong <cyd@gnu.org> wrote:
> IMO, it's desireable for the package.el in Emacs to retain a version
> number header, just in case there is any package that in turn relies on
> package.el (even though sounds pretty theoretical). I propose bumping
> the package.el in Emacs to 1.0. Any objection?
1.0 makes sense considering it will be the first version distributed with Emacs.
-Phil
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-25 5:23 ` Phil Hagelberg
@ 2012-02-25 9:46 ` Stefan Monnier
2012-02-25 22:21 ` Phil Hagelberg
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2012-02-25 9:46 UTC (permalink / raw)
To: Phil Hagelberg; +Cc: 10838
> The problem is there are many versions claiming to be 0.9. The original
> one on tromey.com (which did not support multiple sources) probably has
> the best claim of being "the real 0.9". I think Chong's suggestion of
> releasing 24 with package.el 1.0 makes sense, and if we decide to
> backport a few changes for official 23-compatibility it could be 0.9.1
> or something.
From what I understand, our package.el is the authoritative package.el,
so it can just use Emacs's own version number: no need to name it
"version 1.0".
As for the one that works with Emacs-23: it's just a stop-gap, so it
really doesn't matter what it's called and whether or not it's based on
our code: as long as it exists and works well enough, we're set.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-25 9:46 ` Stefan Monnier
@ 2012-02-25 22:21 ` Phil Hagelberg
0 siblings, 0 replies; 11+ messages in thread
From: Phil Hagelberg @ 2012-02-25 22:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10838
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> From what I understand, our package.el is the authoritative package.el,
> so it can just use Emacs's own version number: no need to name it
> "version 1.0".
Chong had a good point that you could have another package that depends
on a particular feature in package.el; in that case having a version
number to pin it on so you get a clearer error might be advantageous.
-Phil
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-02-25 4:56 ` Chong Yidong
2012-02-25 5:23 ` Phil Hagelberg
@ 2012-03-01 16:49 ` Tom Tromey
2012-03-04 9:45 ` Chong Yidong
1 sibling, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2012-03-01 16:49 UTC (permalink / raw)
To: Chong Yidong; +Cc: 10838, Phil Hagelberg
>>>>> "Chong" == Chong Yidong <cyd@gnu.org> writes:
>> There is a version of package.el which is available from
>> tromey.com/elpa, which is clearly the starting point for this
>> package.el, which claims to be version 0.9 in the head of the file. The
>> current (and emacs23) versions contain this same version number, despite
>> having significantly different features. This is misleading and
>> remarkably confusing. The version numbers in both the emacs24 and
>> emacs23 versions should be updated to indicate that they contain new
>> features.
Chong> IMO, it's desireable for the package.el in Emacs to retain a version
Chong> number header, just in case there is any package that in turn relies on
Chong> package.el (even though sounds pretty theoretical). I propose bumping
Chong> the package.el in Emacs to 1.0. Any objection?
It is fine by me.
FWIW, package.el has a version number so it can be updated using itself.
Tom
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#10838: 24.0.92; package.el shows a misleading version number
2012-03-01 16:49 ` Tom Tromey
@ 2012-03-04 9:45 ` Chong Yidong
0 siblings, 0 replies; 11+ messages in thread
From: Chong Yidong @ 2012-03-04 9:45 UTC (permalink / raw)
To: Tom Tromey; +Cc: 10838, Phil Hagelberg
Tom Tromey <tromey@redhat.com> writes:
> Chong> IMO, it's desireable for the package.el in Emacs to retain a version
> Chong> number header, just in case there is any package that in turn relies on
> Chong> package.el (even though sounds pretty theoretical). I propose bumping
> Chong> the package.el in Emacs to 1.0. Any objection?
>
> It is fine by me.
Done.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-03-04 9:45 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-17 18:40 bug#10838: 24.0.92; package.el shows a misleading version number Phil Hagelberg
2012-02-17 23:46 ` Stefan Monnier
2012-02-18 0:01 ` Phil Hagelberg
2012-02-18 22:40 ` Stefan Monnier
2012-02-25 5:23 ` Phil Hagelberg
2012-02-25 9:46 ` Stefan Monnier
2012-02-25 22:21 ` Phil Hagelberg
2012-02-25 4:56 ` Chong Yidong
2012-02-25 5:23 ` Phil Hagelberg
2012-03-01 16:49 ` Tom Tromey
2012-03-04 9:45 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).