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. > > > 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. agreed > > > > 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/ What I think is that - after releasing 3.0 1.8 -> EOL 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 ). 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. 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: dev-unsubscr...@pdfbox.apache.org > > For additional commands, e-mail: dev-h...@pdfbox.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > -- Maruan Sahyoun --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
