>Hi, > > >> I just hope we can come up with a better PR communication next time, >> and at least for the 2.0. >> So, shall we start the contest again for the 1.1.5 or for the 2.0? > > >I'd say 2.0, as 1.1.5 will not get much visibility (even if it has a new >feature) > >Andre > I think any new name will succeed only if there is an agreeable process in place. As has been mentioned before, on releases@, any process has to accommodate the fact that builds are ready at different times. That said, compromises can be made for the announcements.
Which then raises an interesting point: What is the purposes of the code name? In proprietary space, it is to obfuscate the release identity--to hide how major or minor it is. Would that make sense for us? 1.1.1, for instance, was a micro bug fix. But the bugs were important to some language communties, and the result was that it was rightly greeted as a minor not micro enhancement. But merely using names doesn't convey the relative importance of any one release. Further, in an open source environment, one wants openness. Why would you want to obscure the release identity, whether it is a micor, minor, or major release? (Names do not define that.) At the same time, one wants to maximize the press effect of a splash announcement. I don't think a codename will do that. I do think having a concerted process so that the localized releases can be issued at the same time (more or less) will help. And building excitement for the next release will do it even better. That is, informing people of the bugs fixed, of the features added, of the quality. As to process. We should discuss this (again) on [EMAIL PROTECTED] We have discussed it before, of course. But as Andre's and Christian's comments indicate, we have not arrived at a satisfactory solution. Cheers Louis --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
