Hi, > -----Original Message----- > From: Curt Arnold [mailto:[EMAIL PROTECTED] > Sent: 12 May 2005 19:18 > To: Log4J Developers List > Subject: Re: [VOTE] Release Overview > > > On May 12, 2005, at 12:05 PM, Yoav Shapira wrote: > >>> 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. > >>> > > > > I'd like 1.3 = 1.2 + TRACE. I'm also OK with 1.2.12 = 1.2.11 + > > TRACE. But > > no 1.4/1.5. > > > > I'd prefer 1.2.12 for 1.2.11 + TRACE over 1.3 since that label is > already associated with much more substantial changes. >
Yoav has a good point that skipping the 1.3 label could cause confusion and with that it mind it would probably be better to use the 1.3 label for a branch of 1.2 with trace + *additions* As long as the final decision on the labelling of the branches, and what they mean in terms of stability, compatibility and features are well published and documented on the website, then people will know what to expect. The 1.2 branch could be continued for additional functionality but then there would still be a huge leap to 1.3 based on current cvs head. To me an a.b.c version scheme means that a = major changes in api or functionality b = minor functionality improvements along with bugfixes c = bugfix release > > > > These (Domains, Joran, etc.) ARE huge changes, easily sufficient > > for a 2.0 > > version number IMHO. > > > > However, if we use the big 2.0 for changes that were not expected to > be breaking that would put a psychic barrier to jumping to 3.0 in > short order to introduce intentional breaking changes like final > removal of Category/Level, reducing visiblility of protected members, > finer-grain locking, etc. > > My desire is that we eliminate the unintentional breaking changes > regardless of what version label we assign. However, if we are going > to release a disruptive build, it is best to get all the pain over > with. Maybe would could proceed with the 1.3 release cycle, but > reserve the right to abandon it in preference to a 2.0 release if the > 2.0 branch seems to be coming together in a timely manner. The current cvs head contains breaking changes including the removal of org.apache.log4j.jmx.HierarchyDynamicMBean, org.apache.log4j.spi.ErrorHandler and org.apache.log4j.spi.ErrorCode without any apparent replacement or deprecation cycle. The removal and re-implementation of org.apache.log4j.RollingFileAppender does not maintain compatibility with existing code as it claims in the javadoc as it does not support subclasses. Again no deprecation cycle. I'm not arguing about the validity of these changes, I just think that they can only form an *A* release and a better migration path be provided. Regards Andy > > --------------------------------------------------------------------- > 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]
