I think the risk of creating the impression that 2.0 is stable is too high. The real problem is that 2.0 has been too long in development, there were frustrated users asking a year ago about when it would be released.
Perhaps it’s time to push for a release of 2.0 and aim for a more frequent release cycle after that, to avoid repeating the situation where the stable and trunk versions are years apart? What is holding back 2.0? What features are we *really* holding out on? Can we put together a roadmap - our users often ask for one... -- John On 30 May 2014, at 14:01, Tilman Hausherr <[email protected]> wrote: > I suggest that we come up with a concept of designating "stable versions" (or > "tested versions") for the trunk and put them on the homepage. A stable > version is one with no or only minor regressions, and/or a version that > committers have found to be "good". This would be for users of the 2.0 > version who don't want to read every discussion, and also as a hint for > unhappy 1.8 users. > > I suspect that other open source projects do also have rules to designate > stable versions, but I didn't look at them. > > Proposed rules: > - any committer can designate any version that is older than 24 hours as > stable > - any committer can veto any version as unstable > - any version that has only positive votes is mentioned on > https://pdfbox.apache.org/downloads.html#scm > - there should be up to three versions there > > Tilman >
