You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Andreas Lehmkuehler <an...@lehmi.de> on 2013/04/18 21:11:12 UTC
How to proceed?
Hi,
what is our next target after releasing 1.8.0 and 1.8.1?
We already started some discussions about that topic, but I'd like to have
clarification. Is it time to go for a 2.0 version? If we agree to that goal,
how should we proceed? Should we branch or simply use the trunk?
I'd prefer to continue using the trunk. We are still able to release
bugfix versions using the 1.8-branch. Even a new 1.9 feature release
should be possible by branching the 1.8-branch.
WDYT?
BR
Andreas Lehmkühler
Re: How to proceed?
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 18.04.2013 23:04, schrieb Thomas Chojecki:
> Hi,
>
> Back to topic.
> - I think we should try to focus on type safety first. More generic collections
> and code cleanup.
That's a good point to start.
> - The other thing is the COSWriter. Writting recursive trough the document
> sounds good, but it make it hard updating existing documents incremental. A
> better way is a linked list like object pool. Iterating through the list and
> writting the objects is much easier than running recurisive with
> cross-references and additional checks.
> - a improved pdf parsing mechanic for broken documents.
>
> This is a open source lib and with developer that work only at his free time,
> this can take some time.
>
> On the other hand we have some bugs. Implementing new features won't fix them.
>
> I have mixed feelings and no idea what is the best for the pdfbox.
The best would be to recruit a lot more committers to get the work done,
but that's just a dream. ;-)
I'm sure that our community will grow in the long run and we'll get more
helping hands to get things done.
> Looking at some bigger projects like eclipse 3.x to 4.x which in my opinion,
> mess up the ide. Unfixed bugs, more new bugs and a rewritten lazy framework.
>
> I don't know, but when we start i think the first point will be a good entry
> with the "type safety".
>
> Best regards
> Thomas
BR
Andreas Lehmkühler
Re: How to proceed?
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 19.04.2013 00:50, schrieb Maruan Sahyoun:
> I think there are different levels to think about which are interwoven
>
> a) which use cases do we support - parsing, text extraction, merging, form filling, viewing, creation …. - do we need more? can we drop some?
Perhaps the creation of pdfs using a higher lever api, but that's nothing
for the near future
> b) do we have a good architecture to support these use cases
There are already some discussions about refactoring/reimplementing. I guess we
will find a lot of things which can be done better. We'll see ...
> c) how do we organize the major parts - I think there is already a feeling that pdfbox should be modularized in one way or the other
That's a main topic
> d) which dependencies do we have and where (might belong to b) - e.g. is it a good idea that PDDocument needs awt? So where are the boundaries from byte/file level to COS to PD model to app/tools/utilities …
Some of those dependencies have to be moved/removed when creating modules
> e) which PDF functionality is missing e.g. do we need to have a better support for different PDF versions
There is a lot missing, but we'll see what's important (to us or any
contributor).
> f) efficiency, memory consumption e.g. do we need something like lazy loading
It's always a good idea to tzhink about those topics :-)
> g) as Thomas wrote type safety, generics …. - maybe better object orientation e.g. today some parsing is done in the parsers, some is done in the COS objects (COSString)
I'd like to remove all deprecated stuff as well
> …….
>
> which is the API we agree to keep stable. Is it COS… , PD …..
>
> Thinking about these 'levels' doesn't mean that we do have to address all of these immediately (or at all) but it will help to set the expectations.
>
>
> My initial thoughts are
>
> 2.0
> o get the API levels right byte/token -> COS -> PD -> Utils/awt/.…. -> apps (Debugger, Reader… - will we keep all of them?)
> o "guarantee" PD level for 2.x -> that's our API which means we can freely change everything above and below in the 2.x branch. Document that!
> o type safety, collections …. on PD level first
>
> 2.1
> o improved parser
> o improved object model below PD e.g. decide if parsing from tokens to COS is done in parser or COS object but not mixed
> o more type safety
> …..
>
> 2.2
> o improved writer
> o new "incremental" writer/stamper
> o handling of non WinAnsi
I hope to get that done sooner. I already have an working prototype...
> BR
> Maruan
BR
Andreas Lehmkühler
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
I think there are different levels to think about which are interwoven
a) which use cases do we support - parsing, text extraction, merging, form filling, viewing, creation …. - do we need more? can we drop some?
b) do we have a good architecture to support these use cases
c) how do we organize the major parts - I think there is already a feeling that pdfbox should be modularized in one way or the other
d) which dependencies do we have and where (might belong to b) - e.g. is it a good idea that PDDocument needs awt? So where are the boundaries from byte/file level to COS to PD model to app/tools/utilities …
e) which PDF functionality is missing e.g. do we need to have a better support for different PDF versions
f) efficiency, memory consumption e.g. do we need something like lazy loading
g) as Thomas wrote type safety, generics …. - maybe better object orientation e.g. today some parsing is done in the parsers, some is done in the COS objects (COSString)
…….
which is the API we agree to keep stable. Is it COS… , PD …..
Thinking about these 'levels' doesn't mean that we do have to address all of these immediately (or at all) but it will help to set the expectations.
My initial thoughts are
2.0
o get the API levels right byte/token -> COS -> PD -> Utils/awt/.…. -> apps (Debugger, Reader… - will we keep all of them?)
o "guarantee" PD level for 2.x -> that's our API which means we can freely change everything above and below in the 2.x branch. Document that!
o type safety, collections …. on PD level first
2.1
o improved parser
o improved object model below PD e.g. decide if parsing from tokens to COS is done in parser or COS object but not mixed
o more type safety
…..
2.2
o improved writer
o new "incremental" writer/stamper
o handling of non WinAnsi
BR
Maruan
Am 18.04.2013 um 23:04 schrieb Thomas Chojecki <in...@rayman2200.de>:
> Hi,
> the idea with the branch sounds good but before doing it. As andreas say, we need to clarifi the changes first. A branch is extra work to keep it up to date with the trunk. If we refactor the pdfbox, it will be very hard to merge patches between this versions.
>
> Back to topic.
> - I think we should try to focus on type safety first. More generic collections and code cleanup.
> - The other thing is the COSWriter. Writting recursive trough the document sounds good, but it make it hard updating existing documents incremental. A better way is a linked list like object pool. Iterating through the list and writting the objects is much easier than running recurisive with cross-references and additional checks.
> - a improved pdf parsing mechanic for broken documents.
>
> This is a open source lib and with developer that work only at his free time, this can take some time.
>
> On the other hand we have some bugs. Implementing new features won't fix them.
>
> I have mixed feelings and no idea what is the best for the pdfbox.
>
> Looking at some bigger projects like eclipse 3.x to 4.x which in my opinion, mess up the ide. Unfixed bugs, more new bugs and a rewritten lazy framework.
>
> I don't know, but when we start i think the first point will be a good entry with the "type safety".
>
> Best regards
> Thomas
>
>
> Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
>> I'd think that we should start scoping out 2.0 - what will be covered under that topic. In addition I would see us doing additional bug fix releases and minor enhancements prior to releasing 2.0. My preference would be to branch out 2.0 and keep trunk for working on 1.x as this would be clearer but maybe we should postpone that discussion until we have a better understanding what 2.0 means.
>>
>> Maruan Sahyoun
>>
>>
>> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>>
>>> Hi,
>>>
>>> what is our next target after releasing 1.8.0 and 1.8.1?
>>>
>>> We already started some discussions about that topic, but I'd like to have
>>> clarification. Is it time to go for a 2.0 version? If we agree to that goal,
>>> how should we proceed? Should we branch or simply use the trunk?
>>>
>>> I'd prefer to continue using the trunk. We are still able to release
>>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>>> should be possible by branching the 1.8-branch.
>>>
>>> WDYT?
>>>
>>> BR
>>> Andreas Lehmkühler
>>
>
Re: How to proceed?
Posted by Thomas Chojecki <in...@rayman2200.de>.
Hi,
the idea with the branch sounds good but before doing it. As andreas
say, we need to clarifi the changes first. A branch is extra work to
keep it up to date with the trunk. If we refactor the pdfbox, it will be
very hard to merge patches between this versions.
Back to topic.
- I think we should try to focus on type safety first. More generic
collections and code cleanup.
- The other thing is the COSWriter. Writting recursive trough the
document sounds good, but it make it hard updating existing documents
incremental. A better way is a linked list like object pool. Iterating
through the list and writting the objects is much easier than running
recurisive with cross-references and additional checks.
- a improved pdf parsing mechanic for broken documents.
This is a open source lib and with developer that work only at his free
time, this can take some time.
On the other hand we have some bugs. Implementing new features won't fix
them.
I have mixed feelings and no idea what is the best for the pdfbox.
Looking at some bigger projects like eclipse 3.x to 4.x which in my
opinion, mess up the ide. Unfixed bugs, more new bugs and a rewritten
lazy framework.
I don't know, but when we start i think the first point will be a good
entry with the "type safety".
Best regards
Thomas
Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
> I'd think that we should start scoping out 2.0 - what will be covered under that topic. In addition I would see us doing additional bug fix releases and minor enhancements prior to releasing 2.0. My preference would be to branch out 2.0 and keep trunk for working on 1.x as this would be clearer but maybe we should postpone that discussion until we have a better understanding what 2.0 means.
>
> Maruan Sahyoun
>
>
> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>
>> Hi,
>>
>> what is our next target after releasing 1.8.0 and 1.8.1?
>>
>> We already started some discussions about that topic, but I'd like to have
>> clarification. Is it time to go for a 2.0 version? If we agree to that goal,
>> how should we proceed? Should we branch or simply use the trunk?
>>
>> I'd prefer to continue using the trunk. We are still able to release
>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>> should be possible by branching the 1.8-branch.
>>
>> WDYT?
>>
>> BR
>> Andreas Lehmkühler
>
Re: How to proceed?
Posted by Guillaume Bailleul <gb...@gmail.com>.
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.martinez@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
>
>
>
>
>
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
> Hi,
>
> Am 19.04.2013 17:50, schrieb Andreas Lehmkuehler:
>> Hi,
>>
>> Am 19.04.2013 09:47, schrieb Timo Boehme:
>>> Hi,
>>>
>>> For the 2.0 features:
>>> - switch to Java 1.6
>> What java6 only feature exactly are you thinking about?
>
> First which comes to my mind is a very basic one that IOException can wrap another exception which helps in producing 'good' stack traces. Than there are a number of additional methods in one or the other classes which are handy to use - I already used some but had to work around to commit code to PDFBox.
> In general even such 'basic' projects like Apache Tika have made the transition to 1.6. Furthermore 1.6 already reached end-of-lifetime support by Oracle thus I don't think that there are many current projects using PDFBox and are still based on Java 1.5. My experience with enterprise customers is that Java 1.6 is the currently used version and will be for the next time to come.
Enhancements/new features for annotations. Could be used if we would like to mark properties, methods … with PDF version supported.
Some collection improvements.
Normalizer for Unicode text (could be used for text extraction)
+1 for 1.6 as we shouldn't limit ourselves although we might be able to still use 1.5 only.
>
>
> Best regards,
> Timo
>
>
>>
>>> Best regards,
>>> Timo
>>
>> BR
>> Andreas Lehmkühler
>>
>
>
> --
>
> Timo Boehme
> OntoChem GmbH
> H.-Damerow-Str. 4
> 06120 Halle/Saale
> T: +49 345 4780474
> F: +49 345 4780471
> timo.boehme@ontochem.com
>
> _____________________________________________________________________
>
> OntoChem GmbH
> Geschäftsführer: Dr. Lutz Weber
> Sitz: Halle / Saale
> Registergericht: Stendal
> Registernummer: HRB 215461
> _____________________________________________________________________
>
Re: How to proceed?
Posted by Timo Boehme <ti...@ontochem.com>.
Hi,
Am 19.04.2013 17:50, schrieb Andreas Lehmkuehler:
> Hi,
>
> Am 19.04.2013 09:47, schrieb Timo Boehme:
>> Hi,
>>
>> For the 2.0 features:
>> - switch to Java 1.6
> What java6 only feature exactly are you thinking about?
First which comes to my mind is a very basic one that IOException can
wrap another exception which helps in producing 'good' stack traces.
Than there are a number of additional methods in one or the other
classes which are handy to use - I already used some but had to work
around to commit code to PDFBox.
In general even such 'basic' projects like Apache Tika have made the
transition to 1.6. Furthermore 1.6 already reached end-of-lifetime
support by Oracle thus I don't think that there are many current
projects using PDFBox and are still based on Java 1.5. My experience
with enterprise customers is that Java 1.6 is the currently used version
and will be for the next time to come.
Best regards,
Timo
>
>> Best regards,
>> Timo
>
> BR
> Andreas Lehmkühler
>
--
Timo Boehme
OntoChem GmbH
H.-Damerow-Str. 4
06120 Halle/Saale
T: +49 345 4780474
F: +49 345 4780471
timo.boehme@ontochem.com
_____________________________________________________________________
OntoChem GmbH
Geschäftsführer: Dr. Lutz Weber
Sitz: Halle / Saale
Registergericht: Stendal
Registernummer: HRB 215461
_____________________________________________________________________
Re: How to proceed?
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 19.04.2013 09:47, schrieb Timo Boehme:
> Hi,
>
> For the 2.0 features:
> - switch to Java 1.6
What java6 only feature exactly are you thinking about?
> Best regards,
> Timo
BR
Andreas Lehmkühler
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
Am 19.04.2013 um 09:47 schrieb Timo Boehme <ti...@ontochem.com>:
> Hi,
>
> since it is quite clear that we will have API incompatible changes in 2.x vs. 1.x we need to keep a 1.x branch for further bug-fixing/small improvements also after 2.0. From my point of view the trunk should reflect the most up-to-date development which means 2.x and 1.x would have its own branch. Only if we agree that 2.0 is a very long term goal and we may have quite a number of improvements in 1.x in the mean time it would be better to keep the trunk for 1.x.
Good point - if we can ensure short release cycles I agree that 2.0 should be based on trunk and 1.x will be branched.
>
> However as Thomas wrote not all improvements we plan have to land in 2.0, but 2.0 may be a starting point with better basics to start from and thus 2.0 maybe is not a so long term goal.
>
> The need for branching will arise with the first API incompatible change or an improvement we don't want to maintain in 1.x should be integrated.
>
> For the 2.0 features:
> - switch to Java 1.6
> - my main interest is in the parsing part and here I would like to see
> the current parsers be replaced by a cleaner approach Maruan has
> started with together with parsing on demand;
To me that's also one of the targets for 2.x - the reason why I proposed a step before (modularization, rearrangement of dependencies) is to have a stable API at least at the PD level so we can work on the 'internals' wo affecting the typical user.
> in 2.0 this parser might not be able to parse all documents we can
> handle in 1.x but can be improved later;
IMHO the parsing goal should be
o parse pdfs conforming to the spec
o parse on demand, incremental parsing, forward parsing only (from a page perspective)
o annotate/tag/handle properties, methods … on a PDF version level
o add hooks to allow for handling parsing exceptions to deal with real world PDFs which are not conforming
> this kind of parsing will also require changes and refactoring at the
> COS level; defining an API here we can build on should be part of 2.0
>
Does the COS level API has to be stable? Is that the 'official' API typical users are working with?
Agreed that we need to clean it up.
There I would like to see that the COS object becomes more intelligent so the parser deals with the overall structure, the COS object with the information for itself. This for deserializing/serializing from/into tokens. In addition the methods within the COS objects should be similar e.g. COSNumber has a get method to parse a string COSString doesn't. There parsing can be done within the constructor …
>
> Best regards,
> Timo
>
>
> Am 18.04.2013 23:32, schrieb Andreas Lehmkuehler:
>> Hi,
>>
>> Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
>>> I'd think that we should start scoping out 2.0 - what will be covered
>>> under that topic.
>> > In addition I would see us doing additional bug fix releases and
>> minor enhancements prior
>> > to releasing 2.0. My preference would be to branch out 2.0 and keep
>> trunk for
>> > working on 1.x
>> Hmm, we already have a 1.8 branch, which can be used for further bugfix
>> releases. Do you want to use the 1.x trunk for a possible 1.9 release?
>>
>>> as this would be clearer but maybe we should postpone that discussion
>>> until
>>> we have a better understanding what 2.0 means.
>> I don't want to start a discussion about possible changes at this point.
>> Whatever we will do, I'm pretty sure that there will be some api changes
>> and
>> we should use this fact as basis for our discussion if we branch or not.
>>
>>> Maruan Sahyoun
>>>
>>>
>>> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>>>
>>>> Hi,
>>>>
>>>> what is our next target after releasing 1.8.0 and 1.8.1?
>>>>
>>>> We already started some discussions about that topic, but I'd like to
>>>> have
>>>> clarification. Is it time to go for a 2.0 version? If we agree to
>>>> that goal,
>>>> how should we proceed? Should we branch or simply use the trunk?
>>>>
>>>> I'd prefer to continue using the trunk. We are still able to release
>>>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>>>> should be possible by branching the 1.8-branch.
>>>>
>>>> WDYT?
>>>>
>>>> BR
>>>> Andreas Lehmkühler
>>
>> BR
>> Andreas Lehmkühler
>>
>
>
> --
>
> Timo Boehme
> OntoChem GmbH
> H.-Damerow-Str. 4
> 06120 Halle/Saale
> T: +49 345 4780474
> F: +49 345 4780471
> timo.boehme@ontochem.com
>
> _____________________________________________________________________
>
> OntoChem GmbH
> Geschäftsführer: Dr. Lutz Weber
> Sitz: Halle / Saale
> Registergericht: Stendal
> Registernummer: HRB 215461
> _____________________________________________________________________
>
Re: How to proceed?
Posted by "Martinez, Mel - 1004 - MITLL" <m....@ll.mit.edu>.
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
On 4/19/13 3:47 AM, "Timo Boehme" <ti...@ontochem.com> wrote:
>Hi,
>
>since it is quite clear that we will have API incompatible changes in
>2.x vs. 1.x we need to keep a 1.x branch for further bug-fixing/small
>improvements also after 2.0. From my point of view the trunk should
>reflect the most up-to-date development which means 2.x and 1.x would
>have its own branch. Only if we agree that 2.0 is a very long term goal
>and we may have quite a number of improvements in 1.x in the mean time
>it would be better to keep the trunk for 1.x.
>
>However as Thomas wrote not all improvements we plan have to land in
>2.0, but 2.0 may be a starting point with better basics to start from
>and thus 2.0 maybe is not a so long term goal.
>
>The need for branching will arise with the first API incompatible change
>or an improvement we don't want to maintain in 1.x should be integrated.
>
>For the 2.0 features:
>- switch to Java 1.6
>- my main interest is in the parsing part and here I would like to see
> the current parsers be replaced by a cleaner approach Maruan has
> started with together with parsing on demand;
> in 2.0 this parser might not be able to parse all documents we can
> handle in 1.x but can be improved later;
> this kind of parsing will also require changes and refactoring at the
> COS level; defining an API here we can build on should be part of 2.0
>
>
>Best regards,
>Timo
>
>
>Am 18.04.2013 23:32, schrieb Andreas Lehmkuehler:
>> Hi,
>>
>> Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
>>> I'd think that we should start scoping out 2.0 - what will be covered
>>> under that topic.
>> > In addition I would see us doing additional bug fix releases and
>> minor enhancements prior
>> > to releasing 2.0. My preference would be to branch out 2.0 and keep
>> trunk for
>> > working on 1.x
>> Hmm, we already have a 1.8 branch, which can be used for further bugfix
>> releases. Do you want to use the 1.x trunk for a possible 1.9 release?
>>
>>> as this would be clearer but maybe we should postpone that discussion
>>> until
>>> we have a better understanding what 2.0 means.
>> I don't want to start a discussion about possible changes at this point.
>> Whatever we will do, I'm pretty sure that there will be some api changes
>> and
>> we should use this fact as basis for our discussion if we branch or not.
>>
>>> Maruan Sahyoun
>>>
>>>
>>> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>>>
>>>> Hi,
>>>>
>>>> what is our next target after releasing 1.8.0 and 1.8.1?
>>>>
>>>> We already started some discussions about that topic, but I'd like to
>>>> have
>>>> clarification. Is it time to go for a 2.0 version? If we agree to
>>>> that goal,
>>>> how should we proceed? Should we branch or simply use the trunk?
>>>>
>>>> I'd prefer to continue using the trunk. We are still able to release
>>>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>>>> should be possible by branching the 1.8-branch.
>>>>
>>>> WDYT?
>>>>
>>>> BR
>>>> Andreas Lehmkühler
>>
>> BR
>> Andreas Lehmkühler
>>
>
>
>--
>
> Timo Boehme
> OntoChem GmbH
> H.-Damerow-Str. 4
> 06120 Halle/Saale
> T: +49 345 4780474
> F: +49 345 4780471
> timo.boehme@ontochem.com
>
>_____________________________________________________________________
>
> OntoChem GmbH
> Geschäftsführer: Dr. Lutz Weber
> Sitz: Halle / Saale
> Registergericht: Stendal
> Registernummer: HRB 215461
>_____________________________________________________________________
>
Re: How to proceed?
Posted by Timo Boehme <ti...@ontochem.com>.
Hi,
since it is quite clear that we will have API incompatible changes in
2.x vs. 1.x we need to keep a 1.x branch for further bug-fixing/small
improvements also after 2.0. From my point of view the trunk should
reflect the most up-to-date development which means 2.x and 1.x would
have its own branch. Only if we agree that 2.0 is a very long term goal
and we may have quite a number of improvements in 1.x in the mean time
it would be better to keep the trunk for 1.x.
However as Thomas wrote not all improvements we plan have to land in
2.0, but 2.0 may be a starting point with better basics to start from
and thus 2.0 maybe is not a so long term goal.
The need for branching will arise with the first API incompatible change
or an improvement we don't want to maintain in 1.x should be integrated.
For the 2.0 features:
- switch to Java 1.6
- my main interest is in the parsing part and here I would like to see
the current parsers be replaced by a cleaner approach Maruan has
started with together with parsing on demand;
in 2.0 this parser might not be able to parse all documents we can
handle in 1.x but can be improved later;
this kind of parsing will also require changes and refactoring at the
COS level; defining an API here we can build on should be part of 2.0
Best regards,
Timo
Am 18.04.2013 23:32, schrieb Andreas Lehmkuehler:
> Hi,
>
> Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
>> I'd think that we should start scoping out 2.0 - what will be covered
>> under that topic.
> > In addition I would see us doing additional bug fix releases and
> minor enhancements prior
> > to releasing 2.0. My preference would be to branch out 2.0 and keep
> trunk for
> > working on 1.x
> Hmm, we already have a 1.8 branch, which can be used for further bugfix
> releases. Do you want to use the 1.x trunk for a possible 1.9 release?
>
>> as this would be clearer but maybe we should postpone that discussion
>> until
>> we have a better understanding what 2.0 means.
> I don't want to start a discussion about possible changes at this point.
> Whatever we will do, I'm pretty sure that there will be some api changes
> and
> we should use this fact as basis for our discussion if we branch or not.
>
>> Maruan Sahyoun
>>
>>
>> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>>
>>> Hi,
>>>
>>> what is our next target after releasing 1.8.0 and 1.8.1?
>>>
>>> We already started some discussions about that topic, but I'd like to
>>> have
>>> clarification. Is it time to go for a 2.0 version? If we agree to
>>> that goal,
>>> how should we proceed? Should we branch or simply use the trunk?
>>>
>>> I'd prefer to continue using the trunk. We are still able to release
>>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>>> should be possible by branching the 1.8-branch.
>>>
>>> WDYT?
>>>
>>> BR
>>> Andreas Lehmkühler
>
> BR
> Andreas Lehmkühler
>
--
Timo Boehme
OntoChem GmbH
H.-Damerow-Str. 4
06120 Halle/Saale
T: +49 345 4780474
F: +49 345 4780471
timo.boehme@ontochem.com
_____________________________________________________________________
OntoChem GmbH
Geschäftsführer: Dr. Lutz Weber
Sitz: Halle / Saale
Registergericht: Stendal
Registernummer: HRB 215461
_____________________________________________________________________
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi
> Hi,
>
> Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
>> I'd think that we should start scoping out 2.0 - what will be covered under that topic.
> > In addition I would see us doing additional bug fix releases and minor enhancements prior
> > to releasing 2.0. My preference would be to branch out 2.0 and keep trunk for
> > working on 1.x
> Hmm, we already have a 1.8 branch, which can be used for further bugfix
> releases. Do you want to use the 1.x trunk for a possible 1.9 release?
Yes, I think we should keep the current branch for 1.8.x as well as 1.9.x
>
>> as this would be clearer but maybe we should postpone that discussion until
>> we have a better understanding what 2.0 means.
> I don't want to start a discussion about possible changes at this point.
> Whatever we will do, I'm pretty sure that there will be some api changes and
> we should use this fact as basis for our discussion if we branch or not.
>
We should branch and as mentioned above I'd prefer that we branch 2.0
>> Maruan Sahyoun
>>
>>
>> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>>
>>> Hi,
>>>
>>> what is our next target after releasing 1.8.0 and 1.8.1?
>>>
>>> We already started some discussions about that topic, but I'd like to have
>>> clarification. Is it time to go for a 2.0 version? If we agree to that goal,
>>> how should we proceed? Should we branch or simply use the trunk?
>>>
>>> I'd prefer to continue using the trunk. We are still able to release
>>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>>> should be possible by branching the 1.8-branch.
>>>
>>> WDYT?
>>>
>>> BR
>>> Andreas Lehmkühler
>
> BR
> Andreas Lehmkühler
>
BR Maruan
Re: How to proceed?
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 18.04.2013 22:15, schrieb Maruan Sahyoun:
> I'd think that we should start scoping out 2.0 - what will be covered under that topic.
> In addition I would see us doing additional bug fix releases and minor
enhancements prior
> to releasing 2.0. My preference would be to branch out 2.0 and keep trunk for
> working on 1.x
Hmm, we already have a 1.8 branch, which can be used for further bugfix
releases. Do you want to use the 1.x trunk for a possible 1.9 release?
> as this would be clearer but maybe we should postpone that discussion until
> we have a better understanding what 2.0 means.
I don't want to start a discussion about possible changes at this point.
Whatever we will do, I'm pretty sure that there will be some api changes and
we should use this fact as basis for our discussion if we branch or not.
> Maruan Sahyoun
>
>
> Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
>
>> Hi,
>>
>> what is our next target after releasing 1.8.0 and 1.8.1?
>>
>> We already started some discussions about that topic, but I'd like to have
>> clarification. Is it time to go for a 2.0 version? If we agree to that goal,
>> how should we proceed? Should we branch or simply use the trunk?
>>
>> I'd prefer to continue using the trunk. We are still able to release
>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>> should be possible by branching the 1.8-branch.
>>
>> WDYT?
>>
>> BR
>> Andreas Lehmkühler
BR
Andreas Lehmkühler
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
I'd think that we should start scoping out 2.0 - what will be covered under that topic. In addition I would see us doing additional bug fix releases and minor enhancements prior to releasing 2.0. My preference would be to branch out 2.0 and keep trunk for working on 1.x as this would be clearer but maybe we should postpone that discussion until we have a better understanding what 2.0 means.
Maruan Sahyoun
Am 18.04.2013 um 21:11 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
> Hi,
>
> what is our next target after releasing 1.8.0 and 1.8.1?
>
> We already started some discussions about that topic, but I'd like to have
> clarification. Is it time to go for a 2.0 version? If we agree to that goal,
> how should we proceed? Should we branch or simply use the trunk?
>
> I'd prefer to continue using the trunk. We are still able to release
> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
> should be possible by branching the 1.8-branch.
>
> WDYT?
>
> BR
> Andreas Lehmkühler
Re: How to proceed?
Posted by Guillaume Bailleul <gb...@gmail.com>.
+1 too
On Fri, Apr 26, 2013 at 9:23 AM, Thomas Chojecki <in...@rayman2200.de> wrote:
> Am 26.04.2013 07:36, schrieb Andreas Lehmkühler:
>
>> - use the current trunk for the ongoing development of 2.0.0
>>
>> - use indivual branches for bigger changes in the trunk, as Guillaume
>> did when refactoring xmpbox
>> - use the current 1.8-branch [1] for bugfix-releases, as I did when
>> releasing 1.8.1
>> - a possible 1.9-branch could be created using the 1.8-branch if
>> necessary
>>
>
> +1
>
Re: How to proceed?
Posted by Thomas Chojecki <in...@rayman2200.de>.
Am 26.04.2013 07:36, schrieb Andreas Lehmkühler:
> - use the current trunk for the ongoing development of 2.0.0
> - use indivual branches for bigger changes in the trunk, as Guillaume
> did when refactoring xmpbox
> - use the current 1.8-branch [1] for bugfix-releases, as I did when
> releasing 1.8.1
> - a possible 1.9-branch could be created using the 1.8-branch if
> necessary
+1
Re: How to proceed?
Posted by Leleu Eric <er...@gmail.com>.
Hi,
+1 for the proposal
BR
Eric
2013/4/26 Maruan Sahyoun <sa...@fileaffairs.de>
> Hi Andreas,
>
> sound like you are having a very enjoyable time.
>
> +1 for the proposal
>
> Maruan Sahyoun
>
> Am 26.04.2013 um 07:36 schrieb Andreas Lehmkühler <an...@lehmi.de>:
>
> > Hi,
> >
> > sorry for answering that late but my time is limited at present due to
> > an ongoing family event. :-)
> >
> > There were more or less different opinions about the future layout of
> > our svn repo, but I guess there is a way everybody could agree to.
> >
> > What do you think about the following proposal:
> >
> > - use the current trunk for the ongoing development of 2.0.0
> > - use indivual branches for bigger changes in the trunk, as Guillaume
> > did when refactoring xmpbox
> > - use the current 1.8-branch [1] for bugfix-releases, as I did when
> > releasing 1.8.1
> > - a possible 1.9-branch could be created using the 1.8-branch if
> > necessary
> >
> > Is this something everybody can agree to?
> >
> > BR
> > Andreas Lehmkühler
> >
> > [1] http://svn.apache.org/viewvc/pdfbox/branches/1.8/
> >
> >
> > Am 18.04.13 21:11, schrieb Andreas Lehmkuehler:
> >> Hi,
> >>
> >> what is our next target after releasing 1.8.0 and 1.8.1?
> >>
> >> We already started some discussions about that topic, but I'd like to
> have
> >> clarification. Is it time to go for a 2.0 version? If we agree to that
> >> goal,
> >> how should we proceed? Should we branch or simply use the trunk?
> >>
> >> I'd prefer to continue using the trunk. We are still able to release
> >> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
> >> should be possible by branching the 1.8-branch.
> >>
> >> WDYT?
> >>
> >> BR
> >> Andreas Lehmkühler
> >
> >
>
>
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi Andreas,
sound like you are having a very enjoyable time.
+1 for the proposal
Maruan Sahyoun
Am 26.04.2013 um 07:36 schrieb Andreas Lehmkühler <an...@lehmi.de>:
> Hi,
>
> sorry for answering that late but my time is limited at present due to
> an ongoing family event. :-)
>
> There were more or less different opinions about the future layout of
> our svn repo, but I guess there is a way everybody could agree to.
>
> What do you think about the following proposal:
>
> - use the current trunk for the ongoing development of 2.0.0
> - use indivual branches for bigger changes in the trunk, as Guillaume
> did when refactoring xmpbox
> - use the current 1.8-branch [1] for bugfix-releases, as I did when
> releasing 1.8.1
> - a possible 1.9-branch could be created using the 1.8-branch if
> necessary
>
> Is this something everybody can agree to?
>
> BR
> Andreas Lehmkühler
>
> [1] http://svn.apache.org/viewvc/pdfbox/branches/1.8/
>
>
> Am 18.04.13 21:11, schrieb Andreas Lehmkuehler:
>> Hi,
>>
>> what is our next target after releasing 1.8.0 and 1.8.1?
>>
>> We already started some discussions about that topic, but I'd like to have
>> clarification. Is it time to go for a 2.0 version? If we agree to that
>> goal,
>> how should we proceed? Should we branch or simply use the trunk?
>>
>> I'd prefer to continue using the trunk. We are still able to release
>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>> should be possible by branching the 1.8-branch.
>>
>> WDYT?
>>
>> BR
>> Andreas Lehmkühler
>
>
Re: How to proceed?
Posted by Timo Boehme <ti...@ontochem.com>.
Hi,
+1 from me for your proposal.
Best regards,
Timo
Am 26.04.2013 07:36, schrieb Andreas Lehmkühler:
> Hi,
>
> sorry for answering that late but my time is limited at present due to
> an ongoing family event. :-)
>
> There were more or less different opinions about the future layout of
> our svn repo, but I guess there is a way everybody could agree to.
>
> What do you think about the following proposal:
>
> - use the current trunk for the ongoing development of 2.0.0
> - use indivual branches for bigger changes in the trunk, as Guillaume
> did when refactoring xmpbox
> - use the current 1.8-branch [1] for bugfix-releases, as I did when
> releasing 1.8.1
> - a possible 1.9-branch could be created using the 1.8-branch if
> necessary
>
> Is this something everybody can agree to?
>
> BR
> Andreas Lehmkühler
>
> [1] http://svn.apache.org/viewvc/pdfbox/branches/1.8/
>
>
> Am 18.04.13 21:11, schrieb Andreas Lehmkuehler:
>> Hi,
>>
>> what is our next target after releasing 1.8.0 and 1.8.1?
>>
>> We already started some discussions about that topic, but I'd like to
>> have
>> clarification. Is it time to go for a 2.0 version? If we agree to that
>> goal,
>> how should we proceed? Should we branch or simply use the trunk?
>>
>> I'd prefer to continue using the trunk. We are still able to release
>> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
>> should be possible by branching the 1.8-branch.
>>
>> WDYT?
>>
>> BR
>> Andreas Lehmkühler
>
>
--
Timo Boehme
OntoChem GmbH
H.-Damerow-Str. 4
06120 Halle/Saale
T: +49 345 4780474
F: +49 345 4780471
timo.boehme@ontochem.com
_____________________________________________________________________
OntoChem GmbH
Geschäftsführer: Dr. Lutz Weber
Sitz: Halle / Saale
Registergericht: Stendal
Registernummer: HRB 215461
_____________________________________________________________________
Re: How to proceed?
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
sorry for answering that late but my time is limited at present due to
an ongoing family event. :-)
There were more or less different opinions about the future layout of
our svn repo, but I guess there is a way everybody could agree to.
What do you think about the following proposal:
- use the current trunk for the ongoing development of 2.0.0
- use indivual branches for bigger changes in the trunk, as Guillaume
did when refactoring xmpbox
- use the current 1.8-branch [1] for bugfix-releases, as I did when
releasing 1.8.1
- a possible 1.9-branch could be created using the 1.8-branch if
necessary
Is this something everybody can agree to?
BR
Andreas Lehmkühler
[1] http://svn.apache.org/viewvc/pdfbox/branches/1.8/
Am 18.04.13 21:11, schrieb Andreas Lehmkuehler:
> Hi,
>
> what is our next target after releasing 1.8.0 and 1.8.1?
>
> We already started some discussions about that topic, but I'd like to have
> clarification. Is it time to go for a 2.0 version? If we agree to that
> goal,
> how should we proceed? Should we branch or simply use the trunk?
>
> I'd prefer to continue using the trunk. We are still able to release
> bugfix versions using the 1.8-branch. Even a new 1.9 feature release
> should be possible by branching the 1.8-branch.
>
> WDYT?
>
> BR
> Andreas Lehmkühler
Re: How to proceed?
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
I added the information about patching a branch to the CMS site developer section. Maybe it's helpful for other people too :-)
Maruan Sahyoun
Am 03.05.2013 um 10:50 schrieb Thomas Chojecki <in...@rayman2200.de>:
> Am 01.05.2013 19:56, schrieb Andreas Lehmkuehler:
>> Hi,
>> Am 01.05.2013 11:55, schrieb Thomas Chojecki:
>>> Seems that I missing some basics knowledge about maintaining branches.
>>> I only used branches for bug fix releases without merging. So I would go the way
>>> just committing it on the branch and trunk as separate commits without any
>>> merging attempts. If this is the wrong way, how do I merge the changes from
>>> 2.0.0 into the 1.8.x branch? (like the Oracle JVM error)
>>> Also I thought that the trunk and branch would never be merged at the end, so
>>> why doing it this way?
>> Let's have a look at the 1.8.1 release. When starting with the
>> preparation the branch contained the 1.8.0 source. I did some cherry
>> picking and chose some of
>> fixes which were done in the trunk. I merged those changes to the 1.8-branch.
>> Based on that code I created the 1.8.1 release.
>>> I'm a little bit confused.
>> Maybe we are talking about the very same. :-) I'm using something like this:
>> - checkout the branch
>> - cd to the branch directory
>> - merge some changes from the trunk using "svn merge
>> -cREV1,REV2,REV3... https://svn.apache.org/repos/asf/pdfbox/trunk"
>> - commit the changes
>
> Thx for that explanation. Didn't know about cherry picking in svn and it makes sense :-) This example helps a lot.
> So for me it makes no different merging from the branch to the trunk or vice versa. But if we mainly work on the trunk, it makes sense doing the merge from the trunk to the branch.
>
>>>> A 1.9 branch would only be needed if we really want to release a new version
>>>> including improvements based on the current api. Are you planning to do
>>>> something like that? I'd like to concentrate on the 2.0 and limit the support
>>>> for the old "version" to bugfixes and maybe smaller enhancements.
>>> Hmm, to be honest, I would do that extra work if this would not be too
>>> complicated applying a patch to the branch.
>> I was just wondering if we really need another branch. All bugfixes should go
>> to the 1.8-branch as long as we don't want to release a new feature release.
> I'm just using the wrong wording. I mean maybe setting the branch to 1.9.0-SNAPSHOT as version.
> But this is just nice to have and not really necessary.
>
>> BR
>> Andreas Lehmkühler
>
> Best regards
> Thomas
>
Re: How to proceed?
Posted by Thomas Chojecki <in...@rayman2200.de>.
Am 01.05.2013 19:56, schrieb Andreas Lehmkuehler:
> Hi,
> Am 01.05.2013 11:55, schrieb Thomas Chojecki:
>> Seems that I missing some basics knowledge about maintaining
>> branches.
>> I only used branches for bug fix releases without merging. So I would
>> go the way
>> just committing it on the branch and trunk as separate commits
>> without any
>> merging attempts. If this is the wrong way, how do I merge the
>> changes from
>> 2.0.0 into the 1.8.x branch? (like the Oracle JVM error)
>> Also I thought that the trunk and branch would never be merged at the
>> end, so
>> why doing it this way?
> Let's have a look at the 1.8.1 release. When starting with the
> preparation the branch contained the 1.8.0 source. I did some cherry
> picking and chose some of
> fixes which were done in the trunk. I merged those changes to the
> 1.8-branch.
> Based on that code I created the 1.8.1 release.
>
>
>> I'm a little bit confused.
> Maybe we are talking about the very same. :-) I'm using something like
> this:
> - checkout the branch
> - cd to the branch directory
> - merge some changes from the trunk using "svn merge
> -cREV1,REV2,REV3... https://svn.apache.org/repos/asf/pdfbox/trunk"
> - commit the changes
Thx for that explanation. Didn't know about cherry picking in svn and
it makes sense :-) This example helps a lot.
So for me it makes no different merging from the branch to the trunk or
vice versa. But if we mainly work on the trunk, it makes sense doing the
merge from the trunk to the branch.
>>> A 1.9 branch would only be needed if we really want to release a new
>>> version
>>> including improvements based on the current api. Are you planning to
>>> do
>>> something like that? I'd like to concentrate on the 2.0 and limit
>>> the support
>>> for the old "version" to bugfixes and maybe smaller enhancements.
>>>
>> Hmm, to be honest, I would do that extra work if this would not be
>> too
>> complicated applying a patch to the branch.
> I was just wondering if we really need another branch. All bugfixes
> should go
> to the 1.8-branch as long as we don't want to release a new feature
> release.
>
I'm just using the wrong wording. I mean maybe setting the branch to
1.9.0-SNAPSHOT as version.
But this is just nice to have and not really necessary.
> BR
> Andreas Lehmkühler
Best regards
Thomas
Re: How to proceed?
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 01.05.2013 11:55, schrieb Thomas Chojecki:
> Am 01.05.2013 11:27, schrieb Andreas Lehmkuehler:
>> Am 30.04.2013 20:23, schrieb Thomas Chojecki:
>>
>>> I will start doing first bugfixes and with the issue PDFBOX-1587 we will break
>>> the compatibility to the older version.
>>>
>>> So I have some question to the branches. There is only a 1.8 branch, can I work
>>> on this one to make some bugfixes and improvements that doesn't break the API?
>>> or is it better to set this branch to 1.9?
>> At present all bugfixes should be relevant for the trunk and the branch. So that
>> IMHO there are two possible ways to do some bugfixing:
>>
>> 1) Use the trunk and merge the changes to the 1.8-branch (if needed)
>> 2) Use the 1.8-branch and merge the changes to the trunk (if needed)
>>
>> I don't if one of them is better than the other?
>>
> Seems that I missing some basics knowledge about maintaining branches.
> I only used branches for bug fix releases without merging. So I would go the way
> just committing it on the branch and trunk as separate commits without any
> merging attempts. If this is the wrong way, how do I merge the changes from
> 2.0.0 into the 1.8.x branch? (like the Oracle JVM error)
>
> Also I thought that the trunk and branch would never be merged at the end, so
> why doing it this way?
Let's have a look at the 1.8.1 release. When starting with the preparation the
branch contained the 1.8.0 source. I did some cherry picking and chose some of
fixes which were done in the trunk. I merged those changes to the 1.8-branch.
Based on that code I created the 1.8.1 release.
> I'm a little bit confused.
Maybe we are talking about the very same. :-) I'm using something like this:
- checkout the branch
- cd to the branch directory
- merge some changes from the trunk using "svn merge -cREV1,REV2,REV3...
https://svn.apache.org/repos/asf/pdfbox/trunk"
- commit the changes
>> A 1.9 branch would only be needed if we really want to release a new version
>> including improvements based on the current api. Are you planning to do
>> something like that? I'd like to concentrate on the 2.0 and limit the support
>> for the old "version" to bugfixes and maybe smaller enhancements.
>>
> Hmm, to be honest, I would do that extra work if this would not be too
> complicated applying a patch to the branch.
I was just wondering if we really need another branch. All bugfixes should go
to the 1.8-branch as long as we don't want to release a new feature release.
>>> Jenkins is running on the trunk, right? is there a way to run it on the branch?
>> I've just created a build for the 1.8-branch [2]. The first build doesn't work
>> due to some issues with the jenkins solaris slave ...
>>
>>> Best regards
>>> Thomas
>>
>> BR
>> Andreas Lehmkühler
>>
> Best regards
> Thomas
>
>> [1] https://issues.apache.org/jira/browse/PDFBOX-1589
>> [2] https://builds.apache.org/job/PDFBox%201.8.x/
BR
Andreas Lehmkühler
Re: How to proceed?
Posted by Thomas Chojecki <in...@rayman2200.de>.
Am 01.05.2013 11:27, schrieb Andreas Lehmkuehler:
> Am 30.04.2013 20:23, schrieb Thomas Chojecki:
>
>> I will start doing first bugfixes and with the issue PDFBOX-1587 we
>> will break
>> the compatibility to the older version.
>>
>> So I have some question to the branches. There is only a 1.8 branch,
>> can I work
>> on this one to make some bugfixes and improvements that doesn't break
>> the API?
>> or is it better to set this branch to 1.9?
> At present all bugfixes should be relevant for the trunk and the
> branch. So that
> IMHO there are two possible ways to do some bugfixing:
>
> 1) Use the trunk and merge the changes to the 1.8-branch (if needed)
> 2) Use the 1.8-branch and merge the changes to the trunk (if needed)
>
> I don't if one of them is better than the other?
>
Seems that I missing some basics knowledge about maintaining branches.
I only used branches for bug fix releases without merging. So I would go
the way just committing it on the branch and trunk as separate commits
without any merging attempts. If this is the wrong way, how do I merge
the changes from 2.0.0 into the 1.8.x branch? (like the Oracle JVM error)
Also I thought that the trunk and branch would never be merged at the
end, so why doing it this way?
I'm a little bit confused.
> A 1.9 branch would only be needed if we really want to release a new
> version
> including improvements based on the current api. Are you planning to do
> something like that? I'd like to concentrate on the 2.0 and limit the
> support
> for the old "version" to bugfixes and maybe smaller enhancements.
>
Hmm, to be honest, I would do that extra work if this would not be too
complicated applying a patch to the branch.
>> Jenkins is running on the trunk, right? is there a way to run it on
>> the branch?
> I've just created a build for the 1.8-branch [2]. The first build
> doesn't work
> due to some issues with the jenkins solaris slave ...
>
>> Best regards
>> Thomas
>
> BR
> Andreas Lehmkühler
>
Best regards
Thomas
> [1] https://issues.apache.org/jira/browse/PDFBOX-1589
> [2] https://builds.apache.org/job/PDFBox%201.8.x/
Re: How to proceed?
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 30.04.2013 20:23, schrieb Thomas Chojecki:
> Hi all,
> the voting shows a clear tendency to use the trunk for the 2.0.0 version.
It wasn't a real vote but I guess we have lazy consensus about it.
> Also the step to Java 1.6 as minimum requirement is a positive one.
Yes, I just created a ticket for that change [1]
> I will start doing first bugfixes and with the issue PDFBOX-1587 we will break
> the compatibility to the older version.
>
> So I have some question to the branches. There is only a 1.8 branch, can I work
> on this one to make some bugfixes and improvements that doesn't break the API?
> or is it better to set this branch to 1.9?
At present all bugfixes should be relevant for the trunk and the branch. So that
IMHO there are two possible ways to do some bugfixing:
1) Use the trunk and merge the changes to the 1.8-branch (if needed)
2) Use the 1.8-branch and merge the changes to the trunk (if needed)
I don't if one of them is better than the other?
A 1.9 branch would only be needed if we really want to release a new version
including improvements based on the current api. Are you planning to do
something like that? I'd like to concentrate on the 2.0 and limit the support
for the old "version" to bugfixes and maybe smaller enhancements.
> Jenkins is running on the trunk, right? is there a way to run it on the branch?
I've just created a build for the 1.8-branch [2]. The first build doesn't work
due to some issues with the jenkins solaris slave ...
> Best regards
> Thomas
BR
Andreas Lehmkühler
[1] https://issues.apache.org/jira/browse/PDFBOX-1589
[2] https://builds.apache.org/job/PDFBox%201.8.x/
Re: How to proceed?
Posted by Thomas Chojecki <in...@rayman2200.de>.
Hi all,
the voting shows a clear tendency to use the trunk for the 2.0.0 version.
Also the step to Java 1.6 as minimum requirement is a positive one.
I will start doing first bugfixes and with the issue PDFBOX-1587 we will
break the compatibility to the older version.
So I have some question to the branches. There is only a 1.8 branch, can
I work on this one to make some bugfixes and improvements that doesn't
break the API? or is it better to set this branch to 1.9?
Jenkins is running on the trunk, right? is there a way to run it on the
branch?
Best regards
Thomas