| Re: [rdf4j-dev] Release planning |
|
On 2/09/16 17:19, Peter Ansell wrote:
~8 weeks between minor versions sounds good to me. Previously we had about 4-6 weeks between patch versions which worked fairly well, but extending that to a regular 8 week period should also work. Whether it is 7 or 9 is neither here nor there really in the greater scheme, as long as the dates are available in advance. If reviews for new versions/dependencies are already included in the feature-cutoff period then that is great, but otherwise could you also get some guidance from legal about the expected timeframes for reviewing new dependencies and new dependency versions to add to the basic timelines. Well, first of all, before I can even start the release review, I need to file an IP log, which needs to include all third party dependencies and their status. Only once they are all approved can release review actually start. So I'd rather not risk a late CQ unless there is a very good reason to do so. As for legal's response time: this depends on a number of factors. For each dependency we need to log a Contribution Questionaire (CQ), which are reviewed and approved by the Eclipse legal team. Easiest to review are CQs for libraries that are already approved for other projects - those are just rubberstamped as they've already done the leg work, and you can usally expect them to be approved within 24-48 hours. Then come the so-called diff reviews: CQs for a newer version of an already-approved library. They can usually process these fairly quickly as well - think a matter of days. Hardest are completely new CQs. Here, they will need to do a full code review, and often do background research on the library's contributors, IP ownership of individual classes etc. This can take a long time depending on the size of the library and how well-documented its legal status is. Another factor is that the legal team has limited capacity. If our CQs coincide with the release of another large project, we may see delays in approval. This actually happened for some of our CQs leading up to the 2.0 release, as we were in the middle of the Eclipse Neon release. The legal team do their best to accomodate us, but they can't cut corners. We can try and push through new CQs late in the release cycle if necessary, but it's easier for everyone if we try to log them as soon as possible, and get them approved (or at least under review) before the cutoff. I'm trying to set us up to do proper SemVer, but as you say, that requires that we more clearly specify which part of the code base we consider our public API. I didn't want to tackle that just now, but it's definitely on my radar.Are we strictly following SemVer in terms of the major/minor/patch version naming and public API compatibility together with that timeline? And if so, it would be great to clarify the public API extent. Ie, foo-api modules are obvious additions to the public API, but how far do we go into internal classes before they are classed as internal and able to be deprecated/migrated during the minor versioning cycle. Jeen |