Rogier Wolff wrote: > How about something similar to the > Linux kernel. Odd numbered versions are development, even numbered are > releases.
sounds good to me. > If within less than two months you want to have two real releases, > you'll have to "run ahead" maybe a bit with the version numbers. I think Bruno's idea to use an increment instead of the month is more appropriate then, even if the day we will want to have two real releases within less than two months is probably more far away than Y3K :) Can we agree on: V_MAJOR: YYYY V_MINOR: sequential, odd for development. and even for stable. V_PATCH: for bugfixes on releases ? * right now we'd be 2009.1 in trunk * the next release, with nona-gpu, will hopefully be 2009.2; or it will be 2010.0 * after the next release trunk will be bumped to 2009.3 or 2010.1 respectively the release branching process becomes: 1. when ready to go in release mode, if there was a year change, sync V_MAJOR to the current year. 2. branch out the release branch. 3. in the release branch, bump up V_MINOR to the next even number 4. issue the first tarball (beta) from the release branch 5. in trunk, bump up V_MINOR to the next odd number 6. commit into the release branch only changes required to polish / fix it 7. issue a series of release candidates from the release branch 8. declare the release branch final 9. minimum maintenance on branch there have been different opinions voiced about trunk freeze vs. branching release and letting trunk live. While respecting all opinions - motivation is something personal to each and every individual - I think that imposing a trunk freeze is contrary to the nature of letting software flow free. Open source resources are self-directed. People make decisions for themselves when/what/where they want to contribute. If there is enough interest for a polished release, it will happen. For the past two releases we had the approach of cumulating a lot of trunk development before going into release mode. The pressure has grown so much that the snapshots have become so much user attention and eventually we had a release. In doing so we played a trade-off between those who want the release and those who want to develop further against the latter, artificially slowing down people like Andrew (nona-gpu) or Lukáš (vigra-1.6). Once branched, the release branch may flourish to a polished full and final release, or it may dry and be superseded by the next cycle. This will be an indication whether we branched too early / with not enough interesting features or there was a real need for a release. The plan I currently suggested is a flurry of releases. nobody says this is the right thing to do. It is just an experiment. If we align five release branches (nona-gpu; vigra; new panorama layout; lens calibration; mosaic mode) and they all flourish to release, I will be lucky at 100%. If we get only three releases in between (i.e. two of them don't move past the beta) it will still be better than the past two years / crops of GSoC projects. And even if we get only one, it will still be equivalent to the status quo with the difference that the developers are not stopped by the release. If we don't get *any* release out after all of these projects have been added to trunk, then my proposal is not right for this project. But we won't find out if we don't try. Open source is like free flowing water. When a need becomes big enough, somebody will feel the itch and scratch it. And if nobody feels the itch - or not enough to put in the energy/time that it takes to scratch it, then it is an unimportant itch. Yuv --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
