Hi,

further the discussion about 3.0 - could we look at the open issues and
pick the ones we think we will be working on for 3.0 and assign them
accordingly. Proposal would be to remove the other ones from the 3.0
target (by next Monday?). This way we get a better picture about what's
missing.

I will open a ticket for adding a migration guide which we can create
content for in the days coming. 

WDYT?

BR
Maruan

Am Donnerstag, den 05.11.2020, 12:12 +0100 schrieb Andreas Lehmkuehler:
> 
> 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]
> 

-- 
-- 
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]

Reply via email to