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/
