> 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.
It's more about the scheme and commons terms such LTS and Feature Release not about the schedule itself (see my comment about "... they have more people though ...") > > > > 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. :-( We typically do a mix of bugfixes and features already. Only question is if new features go into an LTS release or not. > > > 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 > +1 for getting it out first and then plan the next steps. > > > > 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] > -- Maruan Sahyoun FileAffairs GmbH Josef-Schappe-Straße 21 40882 Ratingen Tel: +49 (2102) 89497 88 Fax: +49 (2102) 89497 91 [email protected] www.fileaffairs.de Geschäftsführer: Maruan Sahyoun Handelsregister: AG Düsseldorf, HRB 53837 UST.-ID: DE248275827 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
