If they are to be separate units, I vote for separate modules. A common virtual release tag can be applied to both to deal with the synchronization issue.
Dan On Aug 24, 2007, at 18:39, TRANS wrote: > On 8/23/07, Charlie Savage <[EMAIL PROTECTED]> wrote: >>> In the second case the version numbers can diverge. So it allows a >>> little more independence between the two libs. The downside is that >>> one has to keep track of which version of libxml to use for a >>> particular version of libxslt. Not a big deal, really, but there >>> it is >>> nonetheless. Also, something to consider, for this last option, it >>> would be possible to move the libxslt lib over to it's own Rubyforge >>> project (which already exists actually). Maybe that's a better idea? >> >> I'd vote a separate project. > > Sean told me he was indifferent, but half-suggested that we might > merge the two libs completely. I'm not qualified enough to make that > call. But Charlie's makes at least one vote for the separate > project/repo. So unless any of you have anything else to add, I'm > leaning toward that approach. Let me know as soon as you can. I'd like > to get this taken care of over the weekend. > > Thanks, > T. _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
