Jeremy M. Dolan wrote: > In article <[EMAIL PROTECTED]>, Daniel Veditz wrote: > >>Long lived branches are a fact of life > > If Gecko is going to branch, a time stamp for it's version is a very > poor choice.
At the time it was assumed the "real" version would properly go in the Mozilla/5.0 product token (as can be seen in the spec). If that were the case then a branch release of Mozilla/5.xyz would be clearly different from the trunk Mozilla/5.abc > And a time stamp plus some delimiter, and (to Gecko itself) irrelevant > data, like how many days it's been branched [...] is no better. If the main version is a timestamp the variant might as well be one as well, but I don't care too much as long as there's something. > by Netscape Netscape is not the only contributor making branches. > A branch is one thing, but what major rendering changes is Netscape > doing to Gecko in their branch? Why does it have to be a "major" change? People using Netscape want to know whether they're using 6.2.1 vs. 6.2 even though the changes are indetectable (8 fixes) -- unless you happen to be using 6.2 and get hacked, which is not how you want to find out. There were far more bug fixes between 20010904 and 20010904.45 (to use my strawman proposal) than between 20010904 and 20010905. If tracking day to day differences is useful on the trunk surely some sort of branch waypoint is also useful. > If there are major changes needed, > send the patch upstream to Mozilla.org to be integrated into the Gecko > product. You don't have to match exactly, but you should use > Gecko/YYYYMMDD where YYYYMMDD is a version of the REAL Gecko that > would render the same. The branch is "REAL" Gecko. Would you say that Linux kernels off a stable branch (e.g. RedHat, Debian ) are not "REAL" linux because they weren't from the development branch? > If you're altering the Gecko product more then can be kept in sync > with the trunk during your branch, then you should start calling it > NetscapeGecko/anyVersionYouWant. Netscape is not the only one working on branches. In any case changes that *are* made by Netscape are checked into the community mozilla.org source repository from which mozilla.org and other non-Netscape builds are made. >>mozilla.org itself expects the magic 1.0 branch to live as long as a >>year and a half with active derivatives. Those derivatives *will be* >>Gecko derivatives > > I'm not aware of any public plans that discus Mozilla.org's direction > post-1.0. http://www.mozilla.org/roadmap/mozilla-1.0.html > Summary: timestamps don't branch. timestamp+delimiter is an ugly hack. The Gecko version is not a timestamp, it's a version. It happens to be derived from a timestamp, alas, but it is a version. Versions have minor variants. Feel free to suggest a less-ugly proposal, though, Mine was just to get the ball rolling. >>Gecko/20010904.45 // pulled 45 days into a branch > > Who's branch? Gecko's branch? The branch started 20010904 in the mozilla.org repository. Multiple branches started on any given day are possiblebut unlikely. Non-trivial branches will be rare and generally use mozilla milestone builds as a starting point. There will be no confusion, certainly orders of magnitude less than the ambiguity of Gecko/20020107 -- is that the 4am build? the morning/noon build? the evening build? -- and that doesn't seem to bother folks much. >>Gecko/20011019 (rv:0.9.4) // pulled 10/19 based on 0.9.4 > > Separate products. The Gecko component of Mozilla 0.9.7 is also 0.9.7. Too bad that's not what's used for the Gecko token, it would have saved this whole discussion. The rv: comment field would be unnecessary, and branching would be obvious: stick another .x level on it as CVS does, or 0.9.4.1 did. > Shouldn't dbaron be involved in the discussion here? Still enjoying his holidays I expect, or gearing up for school. I hope he does get involved, but if he never shows up it's not required. For something this fundamental to the way mozilla is seen we probably need [EMAIL PROTECTED] ultimately. -Dan Veditz
