On Wed, 2005-05-11 at 22:05 -0700, Mark Womack wrote: > 1) Release 1.2.11 with JMS build fix, maybe some other critical fixes > (action item: determine the other fixes). Timeframe is almost immediate, > within the next 2 weeks.
Agree. > 2) Abandon the 1.3 version number, the main branch becomes version 1.5 > below. As a end-user and developer, I am often confused when versions jump like that. I would still go with 1.3 or 2.0. > 3) Release a 1.4 version with the TRACE change and other fixes that will > make life happier for the user base (action item: determine the other > changes). No major structural changes. Just most "important" bugfixes. > The base of the 1.4 code would start from the v1_2branch. Timeframe is > within a month of the 1.2.11 release. If it's a bug fix release, it should go with 1.2. The TRACE feature is so minor (IMHO) that adding to to 1.2 seems like not a problem. This would confuse users. I bet though, that users will wait for a real 1.3 or 2.0. > 4) Release a 1.5 version based on the current main branch. This would be > what we are calling v1.3 today. Timeframe: release of first final version > by 10/2005. Again, I would stick with 1.3 or 2.0. In summary: Release 1.2.11, release a follow on 1.2.12 with minor features. Release 1.3 this year. (Six months or so is not a long time, though.) IMHO, if a library makes me do just one little change, I would prefer to go with the latest version and make X changes. Because for me, it's the same number of check-ins, same number of bugs to file, same amount of QA iterations for one small change as one larger set of changes. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
