I was just thinking the same thing. Relabeling the 1.3 as 1.5 gives
us the option to do an interim minor release and have something to
call it even if the decision to actually prepare a release to occupy
that number was deferred. And it also preserves the big 2.0 for
bigger changes (so long Category).
+1
On May 12, 2005, at 12:05 AM, Mark Womack wrote:
OK, consolidating the dicussions we have had the past few days, I
would like to propose the following:
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.
2) Abandon the 1.3 version number, the main branch becomes version
1.5 below.
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.
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.
Exact timeline for the 1.5 version is TBD, but I think we have
discussed the basics. I am not proposing we change the version to
2.0. Again, to me that means much bigger changes, and we should
reserve that version number for when we want to make the bigger
changes.
I am +1 on the above, and I am committing to make it happen. I am
willing to be the release manager for the proposed versions. We
will all need to focus and do what we need to complete these
releases, especially v1.5.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
