Am Samstag, dem 14.10.2023 um 13:36 +0200 schrieb Tilman Hausherr: > On 11.10.2023 07:53, sahy...@fileaffairs.de wrote: > > With regards to versioning I'd like to propose that we have 2.0 as > > LTS > > and 4.x being the next LTS.
although both projects can not be compared maybe we can adopt something similar https://camel.apache.org/blog/2020/03/LTS-Release-Schedule/ e.g. we do a 4.0.0 as LTS 4.1.0, 4.2.0 ... will not be 4.3.0 might .... Where 4.x are feature releases with faster increments to what we do today. E.g. we might not implement all PDF 2.0 bits in 4.0 but maybe only for certain parts like annotations, or forms or signature algos .. and then add the next bits in 4.1 and so on planning the boundaries upfront. This way instead of doing a big release like 3.0 after a very long period of time we have faster cycles. Bug fixes will only be done to LTS e.g. in my sample above 4.0 will have patch releases like 4.0.1, 4.0.2 ... but 4.1 will not. We can also limit the lifetime for LTS to a certain (not too long) period of time. Depends on how fast we think me can do minor releases. LTS would receive bug fixes only - no new features. So for users with less critical applications they can adopt quicker. And because we have less new stuff we limit the risk of breaking things. >From that perspective we need to decide for 4.0 what will be breaking changes. Others can be done either in 4.0 or later. E.g. apparance handlers for form widgets can be done in a non breaking but additive manner. BR Maruan > > Yes, very good idea. > > Tilman > > > --------------------------------------------------------------------- > 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
