You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commonsrdf.apache.org by Sergio Fernández <wi...@apache.org> on 2015/05/06 13:23:04 UTC
release notes
Just because I have it fresh, I want to share some notes abuut the
preparation of our first release.
Basically I followed the regular process described at
http://www.apache.org/dev/release-publishing.html using the
maven-release-plugin:
mvn release:clean
mvn release:prepare
mvn release:perform -DconnectionUrl=scm:git:file://`pwd`/.git
git push
git push --tags
The versioning schema agreed is not well supported by the
maven-release-plugin. so I needed to manually fix the api versions by
amending the local commits before performing the release. We should find a
better approach
The commons-parent causes some troubles, not only for us:
https://github.com/apache/commons-vfs/blob/trunk/pom.xml#L538 I tried all,
but it keeps generating a
commons-rdf-parent-x.y.z-incubating-source-release.zip including wrong
things (e.g., examples).
And that's more or less all behind the scenes.
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: release notes
Posted by Sergio Fernández <wi...@apache.org>.
I'd not adopt gitflow in this project, after all sooner than api should be
become stable enough for having small activity at master.
On Fri, May 8, 2015 at 3:23 PM, Stian Soiland-Reyes <st...@apache.org>
wrote:
> Thanks for joining!
>
> So you suggest the git model where master would be at the latest
> non-patch release? (why not just the latest release?)
>
> Not too far off from
> http://nvie.com/posts/a-successful-git-branching-model/
>
> But I think this could be confusing to GitHub users who want to
> contribute with pull requests.. at least during this incubation phase
> where we are open for larger change.
>
>
> On 7 May 2015 at 18:13, Jakob Frank <ja...@apache.org> wrote:
> > Hi all,
> >
> > finally after all this BNode discussion something simple where to start
> > contributing ;-)
> >
> > Am 07.05.2015 16:39 schrieb "Sergio Fernández" <wi...@apache.org>:
> >>
> >> Keeping the api as priority, maybe we can have the rule that master will
> >> always contain X.Y.0-SNAPSHOT version. After all X.Y.Z are maintenance
> >> versions we can keep on their on branch.
> > My suggestion would be to have master on X.Y.0 (no snapshot), and the
> > develop branch for the X.Y+1.0-SNAPSHOT to evolve the API.
> > The X.Y.1 versions should stay on their maintenance branches.
> >
> > Best,
> > Jakob
> >
> >> But I think we should discuss that aspect. That for bring it in, Stian.
> >>
> >> Cheers,
> >>
> >>
> >> --
> >> Sergio Fernández
> >> Partner Technology Manager
> >> Redlink GmbH
> >> m: +43 6602747925
> >> e: sergio.fernandez@redlink.co
> >> w: http://redlink.co
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: release notes
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks for joining!
So you suggest the git model where master would be at the latest
non-patch release? (why not just the latest release?)
Not too far off from http://nvie.com/posts/a-successful-git-branching-model/
But I think this could be confusing to GitHub users who want to
contribute with pull requests.. at least during this incubation phase
where we are open for larger change.
On 7 May 2015 at 18:13, Jakob Frank <ja...@apache.org> wrote:
> Hi all,
>
> finally after all this BNode discussion something simple where to start
> contributing ;-)
>
> Am 07.05.2015 16:39 schrieb "Sergio Fernández" <wi...@apache.org>:
>>
>> Keeping the api as priority, maybe we can have the rule that master will
>> always contain X.Y.0-SNAPSHOT version. After all X.Y.Z are maintenance
>> versions we can keep on their on branch.
> My suggestion would be to have master on X.Y.0 (no snapshot), and the
> develop branch for the X.Y+1.0-SNAPSHOT to evolve the API.
> The X.Y.1 versions should stay on their maintenance branches.
>
> Best,
> Jakob
>
>> But I think we should discuss that aspect. That for bring it in, Stian.
>>
>> Cheers,
>>
>>
>> --
>> Sergio Fernández
>> Partner Technology Manager
>> Redlink GmbH
>> m: +43 6602747925
>> e: sergio.fernandez@redlink.co
>> w: http://redlink.co
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: release notes
Posted by Jakob Frank <ja...@apache.org>.
Hi all,
finally after all this BNode discussion something simple where to start
contributing ;-)
Am 07.05.2015 16:39 schrieb "Sergio Fernández" <wi...@apache.org>:
>
> Keeping the api as priority, maybe we can have the rule that master will
> always contain X.Y.0-SNAPSHOT version. After all X.Y.Z are maintenance
> versions we can keep on their on branch.
My suggestion would be to have master on X.Y.0 (no snapshot), and the
develop branch for the X.Y+1.0-SNAPSHOT to evolve the API.
The X.Y.1 versions should stay on their maintenance branches.
Best,
Jakob
> But I think we should discuss that aspect. That for bring it in, Stian.
>
> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
Re: release notes
Posted by Sergio Fernández <wi...@apache.org>.
Hi,
On Thu, May 7, 2015 at 12:31 AM, Stian Soiland-Reyes <st...@apache.org>
wrote:
>
> Looks much simpler :) Thinking ahead for Commons it should make it
> easier for $anyone to do the release as well.
>
Indeed, that simplifies much more the process.
There are still some small details to have it completely automated. Some
things from commons-parent make it harder. Buty we are close to have it in
the state that anybody would just need:
mvn release:clean
mvn release:prepare
mvn release:perform
>> 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!
>
I had to think the same question, and I could be wrong, but I think we all
here agree the api is the priority of the project.
> 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. ) - 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).
>
Keeping the api as priority, maybe we can have the rule that master will
always contain X.Y.0-SNAPSHOT version. After all X.Y.Z are maintenance
versions we can keep on their on branch.
But I think we should discuss that aspect. That for bring it in, Stian.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: release notes
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 6 May 2015 at 21:34, Sergio Fernández <wi...@apache.org> wrote:
> On Wed, May 6, 2015 at 6:19 PM, Stian Soiland-Reyes <st...@apache.org>
> 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
Re: release notes
Posted by Sergio Fernández <wi...@apache.org>.
On Wed, May 6, 2015 at 6:19 PM, Stian Soiland-Reyes <st...@apache.org>
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
> 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.
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: release notes
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks for preparing the release!
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?)
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?
On 6 May 2015 at 12:23, Sergio Fernández <wi...@apache.org> wrote:
> Just because I have it fresh, I want to share some notes abuut the
> preparation of our first release.
>
> Basically I followed the regular process described at
> http://www.apache.org/dev/release-publishing.html using the
> maven-release-plugin:
>
> mvn release:clean
> mvn release:prepare
> mvn release:perform -DconnectionUrl=scm:git:file://`pwd`/.git
> git push
> git push --tags
>
> The versioning schema agreed is not well supported by the
> maven-release-plugin. so I needed to manually fix the api versions by
> amending the local commits before performing the release. We should find a
> better approach
>
> The commons-parent causes some troubles, not only for us:
> https://github.com/apache/commons-vfs/blob/trunk/pom.xml#L538 I tried all,
> but it keeps generating a
> commons-rdf-parent-x.y.z-incubating-source-release.zip including wrong
> things (e.g., examples).
>
> And that's more or less all behind the scenes.
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718