On 6 May 2015 at 21:34, Sergio Fernández <[email protected]> wrote: > On Wed, May 6, 2015 at 6:19 PM, Stian Soiland-Reyes <[email protected]> > wrote: >> >> Using 0.1.0 style version also on the commons-rdf-api would probably >> simplify a lot for the release plugin.. specially when/if we were to >> try to do the equivalent of a 0.1.1 release of commons-rdf-simple. It >> would also be more in line with semantic versioning to always have 3 >> digits - even if we don't intend to publish a .1 patch of the -api. >> (Any .1 patch of the API would be just textual formatting changes of >> javadoc?) >> > > > +1 to that idea, I've just implemented in commit > 4731519ed6104be1ace423a6198b0d60468d32b3
Looks much simpler :) Thinking ahead for Commons it should make it easier for $anyone to do the release as well. >> I guess you would bump master to be on 0.1.1-SNAPSHOT afterwards, or >> are you setting them to 0.2-SNAPSHOT and 0.2.0-SNAPSHOT? > I'd prefer to focus on the api evolution, so master will be 0.2.0-SNAPSHOT, > while I plan to keep a maintenance branch for 0.1.x. But I happy to listen > opinions about this. On consideration, after this particular release I think I agree that we are aiming for 0.2.0, as we will try to lock down things like the hashCode definitions (COMMONSRDF-14) and verify that in the tests - which can't really be said to be a patch release even though signature-wise the commons-rdf-api could be just the same -- so leaving it as 0.2.0-incubating-SNAPSHOT after the release is probably fine. Sorry for bringing this up! (BTW, I'm working my way through a COMMONSRDF-14 branch for suggested hashCode changes on my bumpy bus rides in the afternoon) I am not sure if we would be able to set a general rule for what the SNAPSHOT version should be after a release -- perhaps when we feel stable the rule would be that "master" would be set for a patch update (e.g. 0.8.1-SNAPSHOT) - which could be revised (e.g. to 0.9.0-SNAPSHOT) if a later change forces a new minor version (for example a new method, or a change of the javadoc contract). Thinking towards graduation and a Commons RDF version 1.0.0, then we would not really want to be making a 1.1.0 version of the commons-rdf-api in the sense of adding new methods to the interfaces, as that would mean breaking existing implementations (even though this would be allowed by Semantic Versioning rules as it does not break existing clients of the API). We could still be clarifying textual contracts - similar to RDF 1.1 vs 1.0. I can see however that it would be allowed to add a new interface in a 1.1.0 without breaking backwards compatibility (e.g. "Dataset" or "Quad") - and similarly any new classes in commons-rdf-simple or in the test harness should also not break anything for implementations or clients. But in general after graduation we should aim for only patches. Note that under Apache Commons versioning guidelines [2] we should never release a 2.0.0 version without changing both artifactId and Java package name - thus allowing co-existing of 1.x and 2.x on the classpath. I think for Commons RDF this is a good stance which hopefully we would not need to face. [2] https://commons.apache.org/releases/versioning.html -- Stian
