Hi,
I support having a 3.0 release because of the new parser.
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.
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]
