On Mon, May 24, 2010 at 12:17 PM, Emmanuel Lecharny <email@example.com>
I didn't had time to rply to Alex' mail. Here it is :
We can either go for Milestone or Minor versions. That does not make a lot of difference to me. The only big difference from the user perspective is that Milestone are more or less seen as not production ready. This is the way Eclipse work, but they have a much strict roadmap, something we don't have.
On 5/24/10 10:14 AM, Stefan Seelmann wrote:
I don't insist on those milestone releases. I just find them useful in
this case to be able to release fast, even if not everything is
finished, and to avoid that users think everything is polished.
Anyway, I totally agree with all your other points. So let's go on.
Alex Karasulu wrote:
On Sun, May 23, 2010 at 11:57 AM, Stefan Seelmann<firstname.lastname@example.org
Alex Karasulu wrote:
> Yes this scheme is much more appealing. However I'm not into this
> milestone designation. I don't really see the point (perhaps someone
> might show me in this thread). Let me explain my thinking below.
> To me you either have a release or you don't release. With the httpd
> scheme above you have no need for milestone releases because 2.0.0,
> 2.1.0, 2.2.0 ... X.Y.0 are milestones in that they introduce new
No sure about that, httpd released a 2.3.5-alpha
Hmmm OK I didn't know that. Regardless though I think the designation is
unnecessary. The new minor release number inherently represents
something that has changed by adding new features which may destabilize
the software. We don't really know how much and if that amount means
give it an alpha flag. How alpha is alpha?
Plus with certain tooling this -alpha designator might be an issue. Why
bother dealing with the risk?
Yes we don't have a solid/strict road map but if we presume we do the minor versions can be used in place of milestones. With minor versions representing feature introductions we're not saying *explicitly* it might not be as stable as we want it to be. Instead we are saying something more like, hey look, this minor release introduces these *new* features. We gave it our best shot so you (our users) can use it and got it out fast to the users for testing. If there are issues we'll fix those issues in micro releases.
We're giving it our best shot to be stable but *implicitly* we're saying it may be patched with micro releases in the future and this is OK IMO.
I don't favor this option though. We will have major refactoring if we release what we have as a 2.0. Here, the message will be : "eh, guys, we are ready" when we are not. I would rather go for a 2.0-RC1 like we did for 1.0, as we had many opportunities to fix many serious issues.
I think we should just release the 2.0.0 in 3 weeks and let people go
wild with it.
I think we can go either way. It's only a matter of how we look at it. As you probably remember I was a fan of RCs before. I now feel I was being a bit rigid. We can lock in the code and do a bunch of RCs to stabilize or we can come out with 2.0.0 and come out with micro releases. NOTE: once we enter the RC release phase we cannot change interfaces anymore just like when we enter 2.0.0. The RC just translates to more stabilizing micro releases on 2.0. Plus I'm starting to think all these designators are really not helping us. Simple and easy is best.
Also unless the software is put into the wild without stigma, some problems will not arise, so they can be fixed fast. The key is to fix the issues without breaking back compatibility so users can upgrade fast without db changes or code changes. Just reinstalling the software will bring them up to date removing issues and this is acceptable.
Also I remember a great email conversation almost 7 years ago on another project's mailing list. It was agreed that releasing fast and releasing often was more important than making sure the code was absolutely stable. Firstly because you can never really be absolutely stable and second because only life in the wild will show if the code is fit enough: fixing sometimes what you think is the big issue does not really fix the big problems in the wild. Third and most important was the idea that stability is not that important. Yeah you heard me right. Just get the feature out and let the user community report the problems so you can fix it fast but fix it fast and release fast. This keeps the user community more involved with the project and communicating with us. It's actually the best way to keep a vibrant community and spend less time testing/improving something which you really cannot tell is broken. You only know in the wild. I'm not saying write and release buggy software and nor were these guys saying this. I'm saying let's fear not providing stability on the first major release. If we blindly stick to the release early release often strategy and communicate with our users, then eventually we will converge towards stability with the least testing effort and the greatest gain in community. So let's make sure we get the releases out fast to fix the issues that arise for our users when they contact us with problems. This way we can stimulate a more vibrant user community while allowing us to focus more time in the right places developing rather than testing.
BTW my only worry with this scheme of major.minor.micro is what if we find a bug that requires extensive changes to the code that breaks with back compatibility? I have not figured out how the release scheme can manage this. Thoughts?
Is it suitable to bump to the next major release number if back compatibility needs to be broken?