* Pretest and branch on Friday June 19
@ 2009-06-12 23:35 Chong Yidong
2009-06-13 1:36 ` Jason Rumney
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Chong Yidong @ 2009-06-12 23:35 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-12 23:35 Pretest and branch on Friday June 19 Chong Yidong
@ 2009-06-13 1:36 ` Jason Rumney
2009-06-14 21:11 ` Stefan Monnier
2009-06-13 4:19 ` Dan Nicolaescu
2009-06-13 20:50 ` Glenn Morris
2 siblings, 1 reply; 9+ messages in thread
From: Jason Rumney @ 2009-06-13 1:36 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-12 23:35 Pretest and branch on Friday June 19 Chong Yidong
2009-06-13 1:36 ` Jason Rumney
@ 2009-06-13 4:19 ` Dan Nicolaescu
2009-06-13 19:09 ` Chong Yidong
2009-06-13 20:50 ` Glenn Morris
2 siblings, 1 reply; 9+ messages in thread
From: Dan Nicolaescu @ 2009-06-13 4:19 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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... )
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-13 4:19 ` Dan Nicolaescu
@ 2009-06-13 19:09 ` Chong Yidong
2009-06-14 14:35 ` joakim
0 siblings, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2009-06-13 19:09 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-12 23:35 Pretest and branch on Friday June 19 Chong Yidong
2009-06-13 1:36 ` Jason Rumney
2009-06-13 4:19 ` Dan Nicolaescu
@ 2009-06-13 20:50 ` Glenn Morris
2009-06-13 21:18 ` Chong Yidong
2 siblings, 1 reply; 9+ messages in thread
From: Glenn Morris @ 2009-06-13 20:50 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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".
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-13 20:50 ` Glenn Morris
@ 2009-06-13 21:18 ` Chong Yidong
2009-06-14 1:50 ` Glenn Morris
0 siblings, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2009-06-13 21:18 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-13 21:18 ` Chong Yidong
@ 2009-06-14 1:50 ` Glenn Morris
0 siblings, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2009-06-14 1:50 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-13 19:09 ` Chong Yidong
@ 2009-06-14 14:35 ` joakim
0 siblings, 0 replies; 9+ messages in thread
From: joakim @ 2009-06-14 14:35 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Pretest and branch on Friday June 19
2009-06-13 1:36 ` Jason Rumney
@ 2009-06-14 21:11 ` Stefan Monnier
0 siblings, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2009-06-14 21:11 UTC (permalink / raw
To: Jason Rumney; +Cc: Chong Yidong, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-06-14 21:11 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-12 23:35 Pretest and branch on Friday June 19 Chong Yidong
2009-06-13 1:36 ` Jason Rumney
2009-06-14 21:11 ` Stefan Monnier
2009-06-13 4:19 ` Dan Nicolaescu
2009-06-13 19:09 ` Chong Yidong
2009-06-14 14:35 ` joakim
2009-06-13 20:50 ` Glenn Morris
2009-06-13 21:18 ` Chong Yidong
2009-06-14 1:50 ` Glenn Morris
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.