Channel names and repo names [was "Proposed post-Fx4 rapid release process"]
John O'Duinn
Looking forward to these new faster-cadence-releases. Looks like some of
my earlier private feedback got lost, so reposting my feedback here as
requested.
>From http://people.mozilla.com/~sayrer/2011/temp/process.html
"The four channels available are: mozilla-central (or "nightly"),
firefox-experimental, firefox-beta, and Firefox (release) [these names
are placeholders]. "
...
"Each release channel is backed by a Mercurial repository containing a
distinct copy of the Firefox source code. "
=====
I understand these placeholder names were to help avoid bikeshedding and
keep people focused on the more important rest of the document. However,
it's time to revisit this, as we're fast running out of time to sort out
two orthogonal-but-interwoven mechanical questions:
1) what repo names to use on hg.m.o?
2) what AUS channel names to use for updates?
We need to make some decisions we can stand by, and then RelEng needs
time to put together the mechanics to make this all happen. The sooner
we can start this work, the better.
I propose that, for Firefox 5.0, we use the following repos and channel
names:
hg.m.o/mozilla-central (users on AUS "nightly" channel)
hg.m.o/releases/mozilla-alpha (users on AUS "alpha" channel)
hg.m.o/releases/mozilla-beta (users on AUS "beta" channel)
hg.m.o/releases/mozilla-3.0 (users on AUS "release" channel)
...and then for Firefox6.0, we'd use:
hg.m.o/mozilla-central (users on AUS "nightly" channel)
hg.m.o/releases/mozilla-alpha (users on AUS "alpha" channel)
hg.m.o/releases/mozilla-beta (users on AUS "beta" channel)
hg.m.o/releases/mozilla-4.0 (users on AUS "release" channel)
...etc, etc.
These names will:
* fit in with our existing naming schemes for automation
* factor in the consolidation of mobile-browser into mozilla-central
* factor in that these repos would also be used by seamonkey and
thunderbird for their own release schedules and support cycles.
* allow us to do chempspill releases in the "mozilla-n.0" repo if needed.
* allow Mozilla to easily communicate the stability of each
nightly/alpha/beta/release train to a *significantly* larger pool of users
Any objections? Anything I'm missing?
tc
John.
=====
Christian Legnitto
Christian
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Henri Sivonen
> I propose that, for Firefox 5.0,
> hg.m.o/releases/mozilla-3.0 (users on AUS "release" channel)
This is a total bikeshed, but could the Gecko version number be the same
as the Firefox version number? It's rather annoying to have two version
number streams that always advance together anyway--especially if the
Gecko number will eventually get values that have already been used for
Firefox.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Robert O'Callahan
> On Mon, 2011-03-28 at 08:20 -0700, John O'Duinn wrote:
> > I propose that, for Firefox 5.0,
>
> > hg.m.o/releases/mozilla-3.0 (users on AUS "release" channel)
>
> This is a total bikeshed, but could the Gecko version number be the same
> as the Firefox version number? It's rather annoying to have two version
> number streams that always advance together anyway--especially if the
> Gecko number will eventually get values that have already been used for
> Firefox.
>
I agree 100%. Please let's synchronize those version numbers.
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Sheppy
> On Mon, 2011-03-28 at 08:20 -0700, John O'Duinn wrote:
> > I propose that, for Firefox 5.0,
> > hg.m.o/releases/mozilla-3.0 (users on AUS "release" channel)
>
> This is a total bikeshed, but could the Gecko version number be the same
> as the Firefox version number? It's rather annoying to have two version
> number streams that always advance together anyway--especially if the
> Gecko number will eventually get values that have already been used for
> Firefox.
+1; this would make documentation easier to produce and read. Having
to constantly correlate Gecko and Firefox version numbers in the docs
gets tedious and confusing.
Eric Shepherd
Developer Documentation Lead
Mozilla
http://www.bitstampede.com/
Christopher Aillon
> On Mon, 2011-03-28 at 08:20 -0700, John O'Duinn wrote:
>> I propose that, for Firefox 5.0,
>
>> hg.m.o/releases/mozilla-3.0 (users on AUS "release" channel)
>
> This is a total bikeshed, but could the Gecko version number be the same
> as the Firefox version number? It's rather annoying to have two version
> number streams that always advance together anyway--especially if the
> Gecko number will eventually get values that have already been used for
> Firefox.
It would make things slightly simpler as a distributor, too. I'd be for
this.
Christian Legnitto
Christian
Mike Beltzner
> I'd like this as well though admittedly I don't know the consequences. Who owns the gecko versioning? The platform team?
Technologically, the consequences are insubstantial, or nor more substantial than any other version increase.
Culturally, there will be bumps (OMG VERSION INFLATION!!!1!!) but I don't think it would be a big problem.
cheers,
mike
Robert O'Callahan
Christian Legnitto
If there are objections I can yank it out again (or someone can submit a pull request!)
Thanks,
Christian
Alexander Limi
--
Alexander Limi · Firefox UX Team · @limi <http://twitter.com/limi> ·
limi.net
On Tue, Mar 29, 2011 at 12:05 PM, Christian Legnitto
<cleg...@mozilla.com>wrote:
Gordon P. Hemsley
This could also have the added benefit (if you'd like to see it that
way) as allowing synchronization with the "Mozilla/5.0" part of the
User-Agent. ...Or is that something that would like to be forgotten?
Gordon
Mike Beltzner
> This could also have the added benefit (if you'd like to see it that
> way) as allowing synchronization with the "Mozilla/5.0" part of the
> User-Agent. ...Or is that something that would like to be forgotten?
Not at all related, turns out.
cheers,
mike
fantasai
>> I propose that, for Firefox 5.0,
>
>> hg.m.o/releases/mozilla-3.0 (users on AUS "release" channel)
>
> This is a total bikeshed, but could the Gecko version number be the same
> as the Firefox version number? It's rather annoying to have two version
> number streams that always advance together anyway--especially if the
> Gecko number will eventually get values that have already been used for
> Firefox.
Asa pointed me at this discussion recently...
So in the past, we considered a major Gecko version number to signal
major API breakage, which we tried to avoid in most releases.
What does the change to every-release-bumps-major-version numbering
imply for API breakage, and how does this impact people who use our
code for other projects? (Was this discussed already?)
~fantasai
Benjamin Smedberg
>
> So in the past, we considered a major Gecko version number to signal
> major API breakage, which we tried to avoid in most releases.
Because we no longer have frozen interfaces, and binary components must
be recompiled for each release, I believe that if the version number
reflects any kind of API meaning, we are being correct. But I also think
we should stop making the version number have proto-meaning with regard
to APIs.
>
> What does the change to every-release-bumps-major-version numbering
> imply for API breakage, and how does this impact people who use our
> code for other projects? (Was this discussed already?)
This has been brought up. It means that external projects will either
need to update every six weeks, or they will need to come up with a
long-term-support system that doesn't involve the Mozilla project
leading the effort. We have made the conscious decision that long term
support is not the best interest of Mozilla.
--BDS
fantasai
> On 5/3/2011 2:06 AM, fantasai wrote:
>>
>> So in the past, we considered a major Gecko version number to signal
>> major API breakage, which we tried to avoid in most releases.
> What kind of API breakage do you think the major gecko number means?
Honestly, I don't know. I don't work on the API side. I just remember
this being the main discussion around the transition from 1.* to 2.0,
and the reason why we kept tacking numbers onto 1.9.
> Because we no longer have frozen interfaces, and binary components
> must be recompiled for each release, I believe that if the version
> number reflects any kind of API meaning, we are being correct. But
> I also think we should stop making the version number have proto-meaning
> with regard to APIs.
>
>> What does the change to every-release-bumps-major-version numbering
>> imply for API breakage, and how does this impact people who use our
>> code for other projects? (Was this discussed already?)
>
> This has been brought up. It means that external projects will either
> need to update every six weeks, or they will need to come up with a
> long-term-support system that doesn't involve the Mozilla project
> leading the effort. We have made the conscious decision that long
> term support is not the best interest of Mozilla.
It's not in the best interest of Firefox or the Mozilla corporation,
but I don't really understand how it's in the best interest of "choice,
innovation" etc. etc. to significantly degrade the ability of other
projects to reuse our code.
I understand not wanting to put effort into maintaining a long-term
branch, but proposing to break any other projects that use Gecko every
6 weeks just seems gratuitous. Forcing them to recompile to push a
security update, okay. But to investigate exactly what changed and
potentially rework how they hook into Gecko--does creating that much
inconvenience for others really gain us that much over batching such
changes into 1-year (or even 6-month) cycles?
I know this doesn't affect me personally. I just find it disturbing
that we've apparently decided that embedding Gecko doesn't matter
to us *at all*, and that everybody wanting a browser engine should
go use WebKit.
~fantasai
Boris Zbarsky
> I know this doesn't affect me personally. I just find it disturbing
> that we've apparently decided that embedding Gecko doesn't matter
> to us *at all*, and that everybody wanting a browser engine should
> go use WebKit.
Note that WebKit doesn't provide any more in the way of API guarantees
than we do, last I checked, for their internal APIs. They have an
embedding API that's a bit more stable than that. But likewise, we
shouldn't be gratuitously changing embedding APIs, and we aren't
planning to. That shouldn't keep us from changing nsINode, say...
-Boris
Zack Weinberg
> I understand not wanting to put effort into maintaining a long-term
> branch, but proposing to break any other projects that use Gecko every
> 6 weeks just seems gratuitous. Forcing them to recompile to push a
> security update, okay. But to investigate exactly what changed and
> potentially rework how they hook into Gecko--does creating that much
> inconvenience for others really gain us that much over batching such
> changes into 1-year (or even 6-month) cycles?
>
> I know this doesn't affect me personally. I just find it disturbing
> that we've apparently decided that embedding Gecko doesn't matter
> to us *at all*, and that everybody wanting a browser engine should
> go use WebKit.
This is just my personal vision, and not one I can back up with hacking
time, but I would like to think that after a few release cycles worth of
intensive rototilling on all the things that we can now overhaul because
they're not frozen anymore, we could come up with a *sane* high-level
external API that we could commit to supporting for a more reasonable
amount of time than six weeks. While being able to drop in arbitrarily
large upgrades to Gecko under that interface.
zw
Philip Chee
That's technically true in the sense that Mozilla isn't planning to
change the embedding APIs, just to remove them from the tree.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Boris Zbarsky
> That's technically true in the sense that Mozilla isn't planning to
> change the embedding APIs, just to remove them from the tree.
Uh... we have no plans to remove the embeddign APIs from the tree.
Hecko, e10s uses our embedding APIs!
We're planning to remove some embedding API shims that convert our
embedding API into some other API from the tree.
-Boris
Benjamin Smedberg
> On 2011-05-03 1:04 PM, fantasai wrote:
>> I understand not wanting to put effort into maintaining a long-term
>> branch, but proposing to break any other projects that use Gecko every
>> 6 weeks just seems gratuitous. Forcing them to recompile to push a
>> security update, okay. But to investigate exactly what changed and
>> potentially rework how they hook into Gecko--does creating that much
>> inconvenience for others really gain us that much over batching such
>> changes into 1-year (or even 6-month) cycles?
>>
>> I know this doesn't affect me personally. I just find it disturbing
>> that we've apparently decided that embedding Gecko doesn't matter
>> to us *at all*, and that everybody wanting a browser engine should
>> go use WebKit.
We previously had a set of gecko interfaces (IDL bits) which were frozen
for binary compatibility. But it turns out that no embedder could
actually get by with using just these interfaces, so it wasn't worth
much. Freezing the set of interfaces which embedders actually need would
involve changing things
Some gecko "clients" including binary extensions have tried to keep up
with interface changes by doing dynamic detection and compiling against
multiple branch versions of nonfrozen interfaces which have changed.
This has not worked well, and has caused lots of crash bugs. So we have
decided to stop allowing this by requiring a recompile for each release
in which any interface changes (which is every release).
The stable embedding APIs (gtkmozembed/ActiveX control/JavXPCOM) didn't
actually work out of the box for anyone in a binary-stable way, and
would require significant changes as we move towards multi-process
content. So rather than causing frustration with coders trying to use
them and realizing that they were half-baked, we have removed in-tree
support for them. It is still possible to use them if you understand the
risks by compiling that code directly into your project.
It is still possible to embed gecko: the core nsIWebBrowser APIs are
still present and we are using them internally for content processes. We
acknowledge that we are not focused on these APIs for external
consumers, and that we want something radically different later.
On 5/3/2011 5:31 PM, Zack Weinberg wrote:
>
> This is just my personal vision, and not one I can back up with
> hacking time, but I would like to think that after a few release
> cycles worth of intensive rototilling on all the things that we can
> now overhaul because they're not frozen anymore, we could come up with
> a *sane* high-level external API that we could commit to supporting
> for a more reasonable amount of time than six weeks. While being able
> to drop in arbitrarily large upgrades to Gecko under that interface.
We *could*, yes. But we have decided that at the current time there are
more important things to do. See
http://groups.google.com/group/mozilla.dev.embedding/browse_thread/thread/73f34c70ef8df30a#
In the world where we primarily run content out of process, the
embedding API would probably work very differently than anything we have
concocted today.
--BDS
Zack Weinberg
>
> We previously had a set of gecko interfaces (IDL bits) which were frozen
> for binary compatibility. But it turns out that no embedder could
> actually get by with using just these interfaces, so it wasn't worth
> much. Freezing the set of interfaces which embedders actually need would
> involve changing things
> On 5/3/2011 5:31 PM, Zack Weinberg wrote:
>> I would like to think that after a few release
>> cycles worth of intensive rototilling on all the things that we can
>> now overhaul because they're not frozen anymore, we could come up with
>> a *sane* high-level external API ...
>
> We *could*, yes. But we have decided that at the current time there are
> more important things to do....
Right. What I was trying to get at was, a period where we don't worry
about external embedders and instead clean up all the rubbish left over
from, among other things, the embedding we used to have, may actually
leave us in *better* shape to provide an embedding API that is both
properly usable and can be stabilized without placing as much burden on
development as the old one did.
We ought perhaps to be *thinking* about this future hypothetical API
now, but only in loose terms -- what does the external interface to
"Gecko" look like, where is the boundary between it and "Firefox".
zw
Philip Chee
Ah, that wasn't clear from the original announcement/thread/discussion
to desupport embedding.