On Wed, 2005-11-30 at 12:46, Curtis L. Olson wrote: > Stefan Seifert wrote: > > > Why the need for an odd subtree then? > > Normal end users use the released packages on the webpage (currently > > 0.9.9). Everyone else, including developers and bleeding edge people > > already check out from CVS. > >
Right now I suspect that most users of FG are either developers or bleeding edge people. But the idea is that that should start changing as of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely? >From then on you need to try and accommodate the "mere users" at the same time as allowing the developers to take the project forwards. But Stefan is right. You can do that with just a 1.1.x release sequence some time after 1.0.x. Trouble is that the developers get robbed of a way of referring to milestones in their own efforts. All they can do is say "this was broken some time after 20060510" referring to the CVS date of a commit. The linux kernel people do at least have the advantage of having "development builds" on the odd-number trees which they can use as absolute references to their progress. That's the only distinction I can see between Stefan's argument and the odd/even numbering system. > > Normally pretty everyone should > > want future updates as soon as they are stable enough for end users. The trick is *not* to do that. Wait a while until you have a set of nice stable goodies for the end-users *then* call a flag day, shift from 1.0.x to 1.2.0 and bring in all the new stuff from 1.1.x in one go. It makes for a better news story on Slashdot/SourceForge/wherever and is more likely to generate column-centimetres in the glossy magazines on real news-stands. > > Linux Kernel versioning has change a _lot_ since 2.6. There is not > > even a real development branch anymore. > They just haven't started 2.7.x yet. They're close to the point where they will though. Linux kernels usually get to .10 on the even tree before the odd tree appears. They're at, what .13 now on the even tree? The odd tree is late, but not massively so. Yet. > I think as flightgear develops and matures, there argument for an > even-stable/odd-devel release system will grow a lot stronger, but for > the moment, development has been moving so quickly with so many new > important features being added, that our attempts at a stable release > have largely been ignored, simply because the devel releases ahead of it > were so much better. > The users up to now have been the developers (see above). > It is interesting to have this discussion though. At the start of this > project, the big focus was to get anyone interested. I was very focused > on generating enough forward progress to keep people from giving up and > moving on to other stuff. At that point I felt like I largely carried > the project on my back and if I would have dropped it, the whole thing > would have quickly died. > Which is why, quite frankly, whatever you say about version numbers is what will happen. That's fine with me, but the fact that we talked about it at all is good. > Now as we look forward, we are talking less about a mad scramble to add > basic features (although there are a few important things left to add) > and more about stability and content (aircraft, scenery, etc.) > It's a bit worse than that though. It was suggested here just a couple of days back that we'd need a way to implement changing aircraft whilst running the program (because everyone else does). That'll likely need a lot of rip-up and replace in the low-level architecture. We might want to change the GUI in a big way. We might want to allow new FDMs to be added, etc etc. You seriously don't want side effects of stuff like that leaking into the users' version of the program until it is very well established amongst the developers that it's all working again and all the loose ends have been tied up. Look what happened to linux kernel around 2.4.9 when someone changed the deep underlying magic in the virtual machine system(*) on the *even* tree and broke the even tree totally for weeks, maybe months. It wasn't until 2.4.14 or thereabouts that the mess got sorted out. > So this discussion of odd/even releases may be a bit premature at the > moment, but it is something we should possibly consider again sometime > after our 1.0 release. > > Curt. Curt - you're the "Linus" of this project. What you say goes. If we people wish to see a given thing done or not done, it's up to us to convince you. And that's what this list is for. Stefan makes valid points above, I think I do too - as will others. There's no right answer, but at least if we've discussed it, we can understand the resulting action or inaction. And change our minds later :-) (*) OK, maybe that wasn't quite what happened, please don't flame me about what *really* happened on this list!!! It's supposed to be just an illustration of how developer stuff got done on the wrong tree(**) and inconvenienced a hell of a lot of people for quite a while. (**) Maybe it wasn't the wrong tree. Maybe it did really have to be done there. But it was an inconvenience for many. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
