Comments: Overwhelmed

http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/2df7eab0c5a03fd4#msg_ad20b9b167b57db6

Posted by Dao at October 20, 2007 1:28 AM

Create a similar 1.9.1.x much like 1.8.1.x was to 1.8.0.x?

Yes there'll be similar drawbacks to the ones you mentioned... but is there any other possible way?

Posted by Gary Kwong at October 20, 2007 2:03 AM

I don't know that I would count the jsm files as a problem... after all, it should be easy to use them if you need them. If it is hard to use them, then that would be a bug.

Posted by Robert Sayre at October 20, 2007 4:29 PM

>>So I don't have a choice - I can't stick them into 1.9. I don't want to try sticking them in a 2.0 build that may undergo radical changes, to where code that passes reviews for 1.x wouldn't be taken for 2.x under the new Mozilla C++ styles.

Maybe the same automated tools that will be used to create the 2.0 codebase can be applied to convert 1.9.x-style patches, or patched 1.9.x code, to 2.0-style code.

(From Alex: I did think about that, but I think it misses the point, since 2.0 code would evolve and 1.9 code wouldn't. Conflictus Onmergus Maximus.)

Posted by James Napolitano at October 21, 2007 9:42 PM

I'd also been wondering what was going to happen between Firefox 3 and Mozilla 2 (Firefox 4?)

Posted by Ian at October 22, 2007 2:47 AM

Maybe we can go, branch off "stable" 1.9 as 1.9.0.x and go for at least a 1.9.1 on trunk, similar to 1.8.1 but even a bit more open...

(From Alex: I'd prefer a 1.10...)

Posted by Robert Kaiser at October 22, 2007 9:31 AM

The fact is, the "1.9.1" plan is still unknown. There's been a lot of talk on IRC and elsewhere about one, but as far I know no concrete plan has emerged.

I certainly hope one will emerge soon!

Posted by Colin Barrett at October 22, 2007 8:22 PM