IIRC I came up with the 4 digits and I was thinking exactly this, we can release many ports of a given tomcat release this way. Having the same number of digits as tomcat won't work. If they used 4 we'd be in trouble :-)
thanks david jencks On May 5, 2010, at 5:43 PM, Ivan wrote: > 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 <[email protected]> > > > On Wed, May 5, 2010 at 7:45 PM, Kevan Miller <[email protected]> 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
