Am 03.11.20 um 20:49 schrieb Tilman Hausherr:
Hi,
I support having a 3.0 release because of the new parser.
OK, so lets proceed with Maruans proposal and try to become feature complete by
the end of November. Once we reached that goal we can think about a first
alpha/beta/release candidate of the trunk as 3.0
I'm against moving to git because I dislike git for its complexity. Git and its
difficulties is probably the most frequent topic on http://dev.to . Using git
means that I will have to spend brain cells on mastering it instead of working
on PDFBox itself. I doubt it will attract new users - PDF is a successful but
20+ year old file format that is "unsexy" for most people.
We should postpone that discussion and move to a fresh thread.
Andreas
Tilman
Am 03.11.2020 um 08:40 schrieb Andreas Lehmkuehler:
Hi,
Am 02.11.20 um 08:45 schrieb Maruan Sahyoun:
Dear fellow dev colleagues,
PDFBox 3.0.0 is in the works for quite some time now. Maybe for too long. Are
we in a position to target a release for end of
year? Maybe by also dropping all open issues which do not have to go into the
release but can be done at a later date because
they add functionality? What's missing, keeping us from doing it?
You are right, it already took too long. We can't wait until it is "perfect".
I've already started to review my tickets and am going to postpone some of the
TODOs on my personal PDFBox list. I hope to come back with a list of TODOs for
3.0 in a couple of days
The other option would be to drop it entirely (move to sandbox or so) and
rebase on the current 2.0 branch as many changes have
been backported and add the important pieces such as the new parser on top of
that.
That would end up in just another 3.0 version but with a lot of additional
work to merge those changes and a lot of chances to introduce new bugs. To sum
it up, IMHO that isn't an option for me.
I'd like to find a way to get the good parts to our users quickly and moving
forward to maybe do smaller, more targeted
increments.
That's a good idea. We should find a way to have some sort of a release plan,
so that our users including ourselves know what to expect. Maybe something
like: one major per year with a list of planned features. A missing feature
won't necessarily block a major release, bugfix releases as needed.
Thoughts? Other/better ideas?
First of all thanks for the valuable input and for starting the discussion. We
are already releasing a lot of stuff but we need to find a way to release the
majors more often.
How about moving to git after the 3.0 release? I'm not one of those guys which
are convinced that only a new tool can solve our issues, but it would have
some advantages compared to svn:
* working with feature branches would make it easier to pick/postpone certain
features for a release
* reviews would be possible without committing the source to the trunk first
* some unrelated side effect w.r.t. to the discussed release issue, it may
attract more new users as people are getting used to use git/github instead of
svn + patches.
Andreas
BR
Maruan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
