geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: [VOTE] Release Geronimo Customized Tomcat 7.0.0.0 (Second Try)
Date Thu, 06 May 2010 00:43:29 GMT
I think that our four version numbers could help us, while Tomcat always has
three version number. In next iteration, we call our version 7.0.0.1, which
means more changes are merged from Tomcat 7 dev tree ......

2010/5/5 Vamsavardhana Reddy <c1vamsi1c@gmail.com>

>
>
> On Wed, May 5, 2010 at 7:45 PM, Kevan Miller <kevan.miller@gmail.com>wrote:
>
>>
>> On May 4, 2010, at 1:56 PM, Joe Bohn wrote:
>>
>> >
>> > +1 (assuming the potential license issue mentioned below is not an
>> issue)
>> >
>> > I was able to build and run the new tomcat image.
>> >
>> > The license issue pointed out last time is now resolved but there is one
>> other potential issue.  I noticed a number of files under jasper-el that are
>> generated using JJTree & JavaCC and so have the following header but no
>> Apache license header.  For example:
>> >
>> > /* Generated By:JJTree&JavaCC: Do not edit this line. ELParser.java */
>> >
>> > Some other generated files include both a generated header and which is
>> immediately followed by the Apache license header.  This seems a little
>> better to me.  However, I see that we have released these without the Apache
>> header in earlier versions (and Tomcat as well) - so I presume there must be
>> some valid justification for not including an Apache License header in these
>> files.  Just pointing it out now in case it really needs some attention and
>> has just escaped being noticed until now.  Comments?
>>
>> I've certainly noticed them in the past... Machine generated files do not
>> require license headers. So, IMO, these files are fine.
>>
>> I do have a question about the version #. IIUC, we are releasing 7.0.0
>> prior to the TC community. There may be fixes applied to the Tomcat dev tree
>> prior to their 7.0 release. So, this release may not exactly match the
>> functionality of the tomcat release. Is everyone evaluating that in their
>> decision?
>>
>> --kevan
>
>
> I think there are two many zeros in the version number too. How about we
> use a version number similar to "6.0.18-G678601" like we have in G 2.x
> builds?
>
> --
> Vamsi
>



-- 
Ivan

Mime
View raw message