Am 03.11.20 um 10:03 schrieb Maruan Sahyoun:
Hi,
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
I'll do the same with mine - pick the open tickets and either assign/mark for
3.0.0 or drop if I won't do ones which are
assigned.
What about targeting to stop actively working on 3.0 by End of Nov and then do
some housekeeping/late fixes in Dec. This way by
end of Nov we might have a feature complete version.
+1
....
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.
I find the release cycle Apache Camel has very attractive (they are more people
though)
https://camel.apache.org/blog/2020/03/LTS-Release-Schedule/
Looks like some common scheme and IMHO quite good, but I'm afraid we haven't the
manpower to support such schedule.
What I think is that - after releasing 3.0
1.8 -> EOL
Yes, I guess we already agreed on that a long time ago. ;-)
2.0 -> LTS release (e.g. to be supported for 2 years)
3.0 is our feature branch
With the feature release we do quarterly increments having a joint discussion
about the major feature(s) upfront to put in
(keeping time for bug fixes, contributions ... etc ).
We are more or less using that schedule for our bugfix releases and again I
don't see the manpower to work on feature releases as well. :-(
And then - maybe in a years time or so - one of the 3.x releases will become
LTS overlapping 2.0 wich will become EOL later and
so on. So for our users there is always a LTS version to keep a stable API and
Java etc. version and a feature version where we
move quicker but have stable releases in between.
Lets concentrate first on getting 3.0 out of the door it is long overdue ...
meanwhile we can collect ideas on how to proceed
A little towards productizing PDFBox. >>
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.
I prefer git over svn and other Apache projects already did the move. But I'm
happy to keep svn if others like to do so.
Branching (although possible in svn), decentralized repo and better tooling
support (with the tools I use) are the features why
I prefer git over svn.
BR
Maruan
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]
