On 09/08/2011 10:46, Mark Thomas wrote: > On 09/08/2011 10:38, Rainer Jung wrote: >> On 09.08.2011 10:37, Mark Thomas wrote: >>> On 08/08/2011 19:44, Rainer Jung wrote: >>>> On 08.08.2011 14:29, Konstantin Kolinko wrote: >>>>> 2011/8/8 Mark Thomas <ma...@apache.org>: >>>>>> On 08/08/2011 12:09, Konstantin Kolinko wrote: >>>>>>> 2011/8/6 Mark Thomas <ma...@apache.org>: >>>>>>>> On 06/08/2011 19:51, Rainer Jung wrote: >>>>>>>>> Anything I have overlooked? >>>>>>>> >>>>>>>> Tagging. >>>>>>>> >>>>>>>> If you use an external, you have to be very careful creating tags else >>>>>>>> the contents of the tag will appear to change over time. >>>>>>>> >>>>>>> >>>>>>> When tc7.0.x branch is created, what is the plan for jdbc-pool? >>>>>>> >>>>>>> Will it be copied over to the branch as well, or we can use externals >>>>>>> pointing to trunk here? >>>>>> >>>>>> I think the best approach would be for 7.0.x to have an external that >>>>>> pointed to trunk but used an explicit revision. That means we have to >>>>>> make a concious decision to update the jdbc-pool in 7.0.x but tagging >>>>>> will just work. It also means experimental work can go on in trunk for >>>>>> jdbc-pool without 'infecting' 7.0.x. >>>>>> >>>>> >>>>> Sounds good. >>>>> We can use the same approach for tcnative. >>>> >>>> Yes, that's a good start. So we would usually set the external in >>>> tcnative to some released TC 7 version, and if there's something >>>> important in the TC 7 branch which is not yet released and should become >>>> part of the tcnative next release, we can make a special TC 7 tag for that. >>> >>> I'd actually go the other way and have 7.0.x have an external to native >>> 1.1.x using the revision associated with the version of native that >>> 7..0.x is currently configured to use. >>> >>> 7.0.x trunk would have an external linking to either 1.1.x head or trunk >>> head. >>> >>> That way we have one copy of the native code to maintain. >> >> Even better :) > > We just need to be careful to end up with the latest versions of everything.
I've been thinking about this some more and how we usually work with this code. On reflection, I think Rainer is right and trunk should be the master copy for this code, with changes ported back to 7.0.x, 6.0.x and 5.5.x as they are now. With that in mind, I think an external from native (1.1.x and trunk) that points to trunk is the way to go. The revision number used for the external can be updated as part of the native release process. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org