On Oct 8, 2:05 pm, Hans <[email protected]> wrote: > A terst setup may be useful. But it will not catch everything. > It is not the answer to determine when a release is deemed to be stable.
I totally agree. But the point is that it makes this question easier to answer. And the better the test setup, the better the answer is. To Dan. I don't think it's a good idea to rename 3.18 to 3.20. 3.18 should be 3.18 and nothing else and 3.20 respectively. If one wants to make x.x0 releases stable to allow easier identification, then why not create those releases? Develop 3.xx to the point of being stable and then release it as 3.20. In this case there is only one, easy to identify stable version. I think this system is used by others too. Releases like 3.20 can be identical to release candidates (which would be 3.18 in this case). If you take operating systems for example you will see that some build is just released under the nice looking, stable version number. With the current system what do you expect on site.config? 3.18? 3.20? 3.18=3.20? 3.18 stable? 3.20 stable? Confusing. When using a revision control system it's worth pointing out that you probably would not release so many development versions. The procedure I think of is the following: * Let's start with some stable version 3.20 * We notice a bug, you fix it and commit it as version 3.21 build1 * The list or others check out the new build and tell you if the fix works * It only partly works, so you fix some more and release as 3.21 build2 * Bad luck, build2 breaks my site, so you release 3.21 build3 * Everyone is satisfied with build3 * You release a stable version 3.21 which is a bug fix release for 3.20 * This can be repeated for 3.22, 3.23 and so on * If you decide that a fix is likely to make a stable version unstable, don't fix it and tell the user to use the unstable version * At the same time you have your vision of version 3.30 with lots of new features * You develop 3.30 build1 to 3.30 build381 and then release 3.30 This way you cannot run out of numbers between 3.20 and 3.30. You exactly know what a version is intended to be (unstable fix, stable fix, unstable cutting edge or stable). You save time by releasing only when it's worth releasing. You could even create a little script that puts the most current build on boltwire.com as an unstable download. Regards, Markus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. 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/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
