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 :
> Am 01.05.2013 19:56, schrieb Andreas Lehmkuehler:
>> Hi,
>> Am 01.05.2013 11:55, schrieb Thomas C
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
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
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 wo
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 tic
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
+1 too
On Fri, Apr 26, 2013 at 9:23 AM, Thomas Chojecki 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
>> - u
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 p
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,
Hi,
+1 for the proposal
BR
Eric
2013/4/26 Maruan Sahyoun
> 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 :
>
> > Hi,
> >
> > sorry for answering that late but my time is limited
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 :
> Hi,
>
> sorry for answering that late but my time is limited at present due to
> an ongoing family event. :-)
>
> There were more or less diff
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
> 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
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 exc
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 h
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
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
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 us
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
Hi,
Am 19.04.2013 um 09:47 schrieb Timo Boehme :
> 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-
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 ow
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 t
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
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
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
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
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 con
27 matches
Mail list logo
