Hi, Regarding the discussion about 'latest work' and 'nearly deliverable work', I share Timo's opinion. When I made deep rework on xmpbox, as proposed by Andreas, I did it in a branch and merged when it was mostly ready. I think it is the best option to prepare the 2.0 because : * we do not know how many time we will need to prepare it, * it will be easier to rollback dead-end or too-long-options on a branch, * patch proposition from non commiters for 1.x will still be done on the trunk which is easier.
About the expectation of the new content, I have very few to say, all the ideas sound good. One thing; we have 2 implementations of xmp in pdfbox. Version 2.x is the opportunity to drop one (and to cut the dependency between pdfbox and an xmp dependency). In a possible future, Adobe will donate its implementation of xmp to Apache. So xmpbox and jempbox could become deprecated. We should prepare that with version 2.0. Concerning the organisation, I just have two propositions: * we should create a wiki to share and summarize all the ideas, information will be lost in long mail threads. * git could be a good idea during the first refactoring phase, WDYT ? Regards, Guillaume On Fri, Apr 19, 2013 at 3:46 PM, Martinez, Mel - 1004 - MITLL < m.marti...@ll.mit.edu> wrote: > I am not a committer, but just to put in my $.02, I totally concur with > Timo on this. > > In my experience, trunk should always represent the 'latest work' that is > likely to have the most enduring lifespan. > > While there will certainly be maintenance bug fixes going into a 1.x > branch that would have to be 'merged up' into 2.0, eventually that would > be expected to tail off and you would move to doing the bulk of your > development in 2.0 - so that should be the trunk. > > Trying to use trunk as the maintenance branch and a separate branch for > the 'going forward' development means that at some point you will be faced > with the painful task of merging/overwriting everything from the 2.0 > branch into trunk. > > No single strategy works for every project or team, of course. But that > is my recommendation. > > Cheers, > > Mel > > > > >
