Re: Emacs pretest 24.2.92

Re: Emacs pretest 24.2.92

[sindikat]

Will CEDET 1.1 be in Emacs 24.3?

Re: Emacs pretest 24.2.92

[Glenn Morris]

sindikat wrote:

> Will CEDET 1.1 be in Emacs 24.3?

emacs-24.2.92 -Q -l cedet
C-h v cedet-version
  -> "1.1"

Re: Emacs pretest 24.2.92

[Stephen J. Turnbull]

Glenn Morris writes:
 > sindikat wrote:
 > 
 > > Will CEDET 1.1 be in Emacs 24.3?
 > 
 > emacs-24.2.92 -Q -l cedet
 > C-h v cedet-version
 >   -> "1.1"
 > 

In XEmacs, we can do

    xemacs -q -eval '(pkg-get-package-info "cedet" "author-version")'

(or something like that, the function may be misspelled).  For
packages that are maintained by a separate project (CEDET, Gnus,
AUCTeX), a similar facility (that doesn't care whether it's Emacs or
GNU ELPA) might be useful in Emacs.

CEDET version [was Re: Emacs pretest 24.2.92]

[Glenn Morris]

Glenn Morris wrote:

> emacs-24.2.92 -Q -l cedet
> C-h v cedet-version
>   -> "1.1"

Yet the Version: header says 1.0pre7.

Re: CEDET version

[Glenn Morris]

Glenn Morris wrote:

>> emacs-24.2.92 -Q -l cedet
>> C-h v cedet-version
>>   -> "1.1"
>
> Yet the Version: header says 1.0pre7.

Hi, could you clarify what the CEDET version is in the emacs-24 branch
and if any of the Version: headers need updating?
Thanks.

Re: CEDET version

[David Engster]

Glenn Morris writes:
> Glenn Morris wrote:
>
>>> emacs-24.2.92 -Q -l cedet
>>> C-h v cedet-version
>>>   -> "1.1"
>>
>> Yet the Version: header says 1.0pre7.
>
> Hi, could you clarify what the CEDET version is in the emacs-24 branch
> and if any of the Version: headers need updating?

Actually, it's more like a 1.2 since 1.1 was already released some time
ago, and the now bundled files are newer.

It is a bit difficult since we bundle a subset of CEDET with Emacs, so
upstream versions cannot be really identical. Since we're now merging
more regularly, maybe we don't need upstream releases anymore and should
see it more as in incubator.

In any case, I think calling this version "1.1.5" or "1.2" should be
fine, but I'd like to know what Eric thinks.

-David

Re: CEDET version

[Glenn Morris]

David Engster wrote:

> Actually, it's more like a 1.2 since 1.1 was already released some time
> ago, and the now bundled files are newer.
>
> It is a bit difficult since we bundle a subset of CEDET with Emacs, so
> upstream versions cannot be really identical. Since we're now merging
> more regularly, maybe we don't need upstream releases anymore and should
> see it more as in incubator.
>
> In any case, I think calling this version "1.1.5" or "1.2" should be
> fine, but I'd like to know what Eric thinks.

We can call it whatever version number you like. I think the only real
issue is when using ELPA to install a newer version of CEDET than the
version supplied with Emacs (but maybe this won't be happening?).

There are various things that this affects; see M-x list-packages
output. semantic, srecode, inversion, pulse, ede, etc. They all have
different version numbers at present.

Re: CEDET version

[Eric M. Ludlam]

On 01/21/2013 09:00 PM, Glenn Morris wrote:
> David Engster wrote:
>
>> Actually, it's more like a 1.2 since 1.1 was already released some time
>> ago, and the now bundled files are newer.
>>
>> It is a bit difficult since we bundle a subset of CEDET with Emacs, so
>> upstream versions cannot be really identical. Since we're now merging
>> more regularly, maybe we don't need upstream releases anymore and should
>> see it more as in incubator.
>>
>> In any case, I think calling this version "1.1.5" or "1.2" should be
>> fine, but I'd like to know what Eric thinks.

I'm ok with either of those version numbers.  If official released 
CEDETs are now whatever shows up in Emacs core, that would be fine with 
me also.  Wrapping up a release, and figuring out how to get it to 
safely overlay in Emacs is a bit challenging.

> We can call it whatever version number you like. I think the only real
> issue is when using ELPA to install a newer version of CEDET than the
> version supplied with Emacs (but maybe this won't be happening?).
>
> There are various things that this affects; see M-x list-packages
> output. semantic, srecode, inversion, pulse, ede, etc. They all have
> different version numbers at present.

These used to all go out separately and were later merged into once 
CEDET package.  Is there a reason to version-merge them?  To be honest, 
updating all those version numbers each time we prep a release is a bit 
of a pain, and they all install together.  The cross-version-checking 
isn't as useful a tool as it once was.

I do have some scripts I use to manage version numbers though.  It could 
be that whenever a merge occurs, we add running this script to the merge 
recipe and that will help.

Eric

Re: CEDET version

[Glenn Morris]

"Eric M. Ludlam" wrote:

>> There are various things that this affects; see M-x list-packages
>> output. semantic, srecode, inversion, pulse, ede, etc. They all have
>> different version numbers at present.
>
> These used to all go out separately and were later merged into once
> CEDET package.  Is there a reason to version-merge them? 

I'm not asking for any changes like that, I'm just asking for someone to
who knows about CEDET versioning to check that all the version numbers
the components have in Emacs make sense. Eg the first one I look at is
semantic.el, which says:

  ;; Version: 2.0
  [...]
  (defvar semantic-version "2.1beta"

Ie, inconsistent in the same way that cedet.el is.

I don't have any opinion on what the version numbers should be, I am
saying that these two should be consistent, and asking what value to
use. I have no idea what version of CEDET, semantic, etc are actually in
Emacs.

Re: CEDET version

[Eric M. Ludlam]

On 01/22/2013 02:10 PM, Glenn Morris wrote:
> "Eric M. Ludlam" wrote:
>
>>> There are various things that this affects; see M-x list-packages
>>> output. semantic, srecode, inversion, pulse, ede, etc. They all have
>>> different version numbers at present.
>>
>> These used to all go out separately and were later merged into once
>> CEDET package.  Is there a reason to version-merge them?
>
> I'm not asking for any changes like that, I'm just asking for someone to
> who knows about CEDET versioning to check that all the version numbers
> the components have in Emacs make sense. Eg the first one I look at is
> semantic.el, which says:
>
>    ;; Version: 2.0
>    [...]
>    (defvar semantic-version "2.1beta"
>
> Ie, inconsistent in the same way that cedet.el is.

Ah, thanks for clarifying.  I hadn't realized the comment and variable 
were going out of sync.  A side-effect of using an incomplete script.  I 
can update the script to keep those in sync in the future the CEDET 
repository.  The variable is the correct version.

I'm not certain about the 'beta' though.  I usually put a number after 
the beta, like 2.1beta1 or some such.

Thanks
Eric

Re: CEDET version

[David Engster]

Eric M. Ludlam writes:
> Ah, thanks for clarifying.  I hadn't realized the comment and variable
> were going out of sync.  A side-effect of using an incomplete script.
> I can update the script to keep those in sync in the future the CEDET
> repository.  The variable is the correct version.
>
> I'm not certain about the 'beta' though.  I usually put a number after
> the beta, like 2.1beta1 or some such.

OK, but what should be done now?

If you bump the numbers in CEDET upstream to a stable version, I can
merge that change to the emacs-24 branch.

For the future, I'd rather get rid of all those separate version numbers
for all the sub-packages. They may have been useful back in the day, but
I don't think they're worth the hassle now. Let's just have one CEDET
version and be done with it.

-David

Re: CEDET version

[Eric M. Ludlam]

On 01/23/2013 02:38 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> Ah, thanks for clarifying.  I hadn't realized the comment and variable
>> were going out of sync.  A side-effect of using an incomplete script.
>> I can update the script to keep those in sync in the future the CEDET
>> repository.  The variable is the correct version.
>>
>> I'm not certain about the 'beta' though.  I usually put a number after
>> the beta, like 2.1beta1 or some such.
>
> OK, but what should be done now?
>
> If you bump the numbers in CEDET upstream to a stable version, I can
> merge that change to the emacs-24 branch.

Ok.  There were pretty big changes in the file system and merges across 
all the parts of CEDET to warrant a version bump.

Or...

> For the future, I'd rather get rid of all those separate version numbers
> for all the sub-packages. They may have been useful back in the day, but
> I don't think they're worth the hassle now. Let's just have one CEDET
> version and be done with it.

...we could just remove all the version numbers, and call it CEDET 2.0.

If there are dependencies out there on the version numbers, it shouldn't 
be too hard to redirect to the overall cedet version.

Doing that will be more work than just running my script.  I've got 
cub-scout overload the next two weeks coming on with a pinewood derby. 
Is there a time crunch on this?

Eric

Re: CEDET version

[David Engster]

Eric M. Ludlam writes:
>> For the future, I'd rather get rid of all those separate version numbers
>> for all the sub-packages. They may have been useful back in the day, but
>> I don't think they're worth the hassle now. Let's just have one CEDET
>> version and be done with it.
>
> ...we could just remove all the version numbers, and call it CEDET 2.0.
>
> If there are dependencies out there on the version numbers, it
> shouldn't be too hard to redirect to the overall cedet version.
>
> Doing that will be more work than just running my script.  I've got
> cub-scout overload the next two weeks coming on with a pinewood
> derby. Is there a time crunch on this?

We cannot do that for the coming release, since the emacs-24 branch has
been in a freeze for quite some time now. So please let's first bump the
versions, which I'll merge to emacs-24, and then rip out the versioning
code, which I can merge to current trunk.

-David

Re: CEDET version

[Eric M. Ludlam]

On 01/23/2013 03:39 PM, David Engster wrote:
> Eric M. Ludlam writes:
>>> For the future, I'd rather get rid of all those separate version numbers
>>> for all the sub-packages. They may have been useful back in the day, but
>>> I don't think they're worth the hassle now. Let's just have one CEDET
>>> version and be done with it.
>>
>> ...we could just remove all the version numbers, and call it CEDET 2.0.
>>
>> If there are dependencies out there on the version numbers, it
>> shouldn't be too hard to redirect to the overall cedet version.
>>
>> Doing that will be more work than just running my script.  I've got
>> cub-scout overload the next two weeks coming on with a pinewood
>> derby. Is there a time crunch on this?
>
> We cannot do that for the coming release, since the emacs-24 branch has
> been in a freeze for quite some time now. So please let's first bump the
> versions, which I'll merge to emacs-24, and then rip out the versioning
> code, which I can merge to current trunk.

Hi David,

In CEDET / bzr repository, change 8466 contains minor version bumping 
and making the comments match the variables.

Thanks
Eric

Re: CEDET version

[David Engster]

Eric M. Ludlam writes:
> In CEDET / bzr repository, change 8466 contains minor version bumping
> and making the comments match the variables.

Thanks. I merged that change to emacs-24.

-David