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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
