Pretest and branch on Friday June 19

Pretest and branch on Friday June 19

[Chong Yidong]

Following discussion with Stefan, I plan to make the next pretest,
23.0.95, next Friday (June 19).  At that time, I will also cut the
EMACS_23_BASE branch and open the trunk for development.  If we need a
23.0.96 pretest, it will be made from the branch.

I'm not certain what version number to assign the trunk after branching.
I'm inclined to use 23.1.50, which assumes we'll use the trunk for
developing 23.2.  Maybe this is optimistic; as many will recall, what
ended up as Emacs 22 was originally slated for 21.3.  Opinions welcome.

Re: Pretest and branch on Friday June 19

[Jason Rumney]

Chong Yidong wrote:
> I'm not certain what version number to assign the trunk after branching.
> I'm inclined to use 23.1.50, which assumes we'll use the trunk for
> developing 23.2.  Maybe this is optimistic; as many will recall, what
> ended up as Emacs 22 was originally slated for 21.3.  Opinions welcome.
>   

I don't think there are major changes like multi-tty or unicode pending, 
but there are a lot of minor features being held back, so 23.1.50 seems 
appropriate to me. When someone comes up with a major new feature 
(collaborative editing, or bidi becoming close to usable), we can 
develop that on a branch like was done with unicode and multi-tty 
(hopefully by then we will be using bzr).

Re: Pretest and branch on Friday June 19

[Stefan Monnier]

>> I'm not certain what version number to assign the trunk after branching.
>> I'm inclined to use 23.1.50, which assumes we'll use the trunk for
>> developing 23.2.  Maybe this is optimistic; as many will recall, what
>> ended up as Emacs 22 was originally slated for 21.3.  Opinions welcome.

It's indeed possible that we end up releasing a 23.2 that's
bug-fix only.  But I wouldn't worry too much about version numbers in
this respect.

> I don't think there are major changes like multi-tty or unicode
> pending, but there are a lot of minor features being held back, so
> 23.1.50 seems appropriate to me.

Indeed, the plan for 23.2 is to add various non-disruptive features
(packages, ...).  If we start with the safest ones, we can minimize the
risk of having to release 23.2 from the 23.1 branch.

> When someone comes up with a major new feature (collaborative editing,
> or bidi becoming close to usable), we can develop that on a branch
> like was done with unicode and multi-tty (hopefully by then we will be
> using bzr).

AFAIK the major upcoming features for 24 would be lexical scoping
and bidi.  Collaborative editing might be doable without major changes.

This said, I'd like to know what's the Bzr story.  We're pretty much
at the point where we'd be happy to do the switch, so we should get
read"y for it.  But if there are still things missing, it'll have to wait
for "post release".


        Stefan

Re: Pretest and branch on Friday June 19

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Following discussion with Stefan, I plan to make the next pretest,
  > 23.0.95, next Friday (June 19).  At that time, I will also cut the
  > EMACS_23_BASE branch and open the trunk for development.  If we need a
  > 23.0.96 pretest, it will be made from the branch.
  > 
  > I'm not certain what version number to assign the trunk after branching.
  > I'm inclined to use 23.1.50, which assumes we'll use the trunk for
  > developing 23.2.  Maybe this is optimistic; as many will recall, what
  > ended up as Emacs 22 was originally slated for 21.3.  Opinions welcome.

Shouldn't the numbering depend on the plan for the release after 23.1?
Is lexical binding going to be added?  (or some similar major feature)?
Or just incremental work? (bug fixing/adding packages/etc)?

(Well, actually the numbering is much less important than the plan... )

Re: Pretest and branch on Friday June 19

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Shouldn't the numbering depend on the plan for the release after 23.1?
> Is lexical binding going to be added?  (or some similar major feature)?
> Or just incremental work? (bug fixing/adding packages/etc)?

Lexical binding will probably be for Emacs 24.  What I have in mind is
to use the trunk for developing 23.x for the next year or so,
incorporating a bunch of relatively safe or self-contained new features
alongside the usual bug fixes.  For instance, I'd like to get CEDET into
Emacs 23.2.

Re: Pretest and branch on Friday June 19

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>> Shouldn't the numbering depend on the plan for the release after 23.1?
>> Is lexical binding going to be added?  (or some similar major feature)?
>> Or just incremental work? (bug fixing/adding packages/etc)?
>
> Lexical binding will probably be for Emacs 24.  What I have in mind is
> to use the trunk for developing 23.x for the next year or so,
> incorporating a bunch of relatively safe or self-contained new features
> alongside the usual bug fixes.  For instance, I'd like to get CEDET into
> Emacs 23.2.

Nice! I have no opinion on the numbering, but it would be interesting to
see a plan for how the following features could be implemented in
different versions:

- Cedet
- Window groups
- Ecb
- The lexical branch

Then it would be really nice to have a plan how the
thoroughly annoying emacs-get-stuck-when-nics-change bug could be fixed. 

>
-- 
Joakim Verona

Re: Pretest and branch on Friday June 19

[Glenn Morris]

Chong Yidong wrote:

> I'm not certain what version number to assign the trunk after branching.
> I'm inclined to use 23.1.50, which assumes we'll use the trunk for
> developing 23.2.

I think it depends on what Emacs version numbers are supposed to mean.

If a bump in the major version means "major new feature(s)" (eg
unicode, multi-tty), then yes, do what you said.

Personally, I like the convention Emacs 22 fell into:
Going from 22.1 to 22.2, only bug fixes or entirely self-contained new
features (eg a brand new package "foo-mode.el") were allowed. This
meant 22.2 could never be worse than 22.1 in any aspect.

I'd like the same thing to happen again for the 23 series.
I don't see it as a problem if there is only ever a 23.2, with very
few (bug-fix or entirely new packages) changes over 23.1, and if 24.1
comes along relatively quickly with no "huge" changes. Version numbers
are cheap.

If the trunk is used for 23.2, then I feel like I'd have to hold off
making non-bugfix changes to any existing feature, in case of
inadvertent breakage. The feature freeze is already almost a year old,
and it's rather disheartening not to be able to do development.

So I think I'd prefer "24.0.50".

Re: Pretest and branch on Friday June 19

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> If the trunk is used for 23.2, then I feel like I'd have to hold off
> making non-bugfix changes to any existing feature, in case of
> inadvertent breakage. The feature freeze is already almost a year old,
> and it's rather disheartening not to be able to do development.

Do you have a specific feature in mind, that you'd be uncomfortable
developing on a 23.x trunk?

The one example I can think of, right now, is the window groups feature,
assuming its implementation turns out to require big changes in the
window-handling code.  But IIRC, one of the proposals to implement
window groups was surprisingly non-invasive and self-contained, and I
think it could be done in a 23.x trunk.

Re: Pretest and branch on Friday June 19

[Glenn Morris]

Chong Yidong wrote:

> Do you have a specific feature in mind, that you'd be uncomfortable
> developing on a 23.x trunk?

I'm not thinking of anything in particular, big or small. I just quite
liked the general principle that 22.2 could never (in theory) be any
worse than 22.1. If one allows for non-bugfix, non-self-contained new
features in 23.2, then this guarantee goes away. Or, if one doesn't
allow for such changes, then developing on a 23.x trunk means delaying
such changes till after the 23.x series.

Perhaps this is just being overly cautious though.