Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] Next patch release and new committers


On 26 Apr 2017, at 23:11, James Leigh <james.leigh@xxxxxxxxxxxx> wrote:

Havard,

I've run some tests on your branch. I'm not sure if issue #535 should be
included in this release though. Also, the version number will need to
be changed before a release. Below are the issues that are currently in
the release branch:

     * #803 SailChangedEvent
     * #792 Encode dollar sign in repository template replacement
     * #787 CookieHandlers now check for empty context path string
     * #786 Catch NumberFormatException when checking server protocol
     * #781 Use hashCode of PathIteration
     * #775 Convert bytes to hex string with leading zeros
     * #773 Check for handler not null instead of null -rdfjson-null
     * #764 Include additional headers in sesame session requests
     * #759 Use fixed Locale.ENGLISH for XML error verification
     * #754 Fix serialisation of language tag in toSPARQL
     * #752 updated benchmark pom and applied renaming
     * #747 Don't encode TSV literals in quotes unless needed
     * #695 Don't treat path modifiers as subqueries
     * #637 Prompt user if using incompatible chars in repository ID
     * #535 Made timeout configurable

Looks good. Why are you unsure about #535? I’m not fussed either way so if you prefer to leave it for a future minor release that’s fine with me.

I haven’t had a chance yet to look at the branch and run tests locally, but I’ve put Hudson to work on it: https://hudson.eclipse.org/rdf4j/job/rdf4j-verify-branch/63/  and that fails due to version number errors, so indeed that should be fixed first. 

As for the version: for the release branch that should be set to 2.2.1-SNAPSHOT. You can use the command `mvn versions:set` and `mvn versions:commit` for this (see the guide on docs.rdf4j.org for details). Once we’re good to release, it can be finalised and set to 2.2.1 before the commit is tagged and we proceed with the actual release. 

How are you finding the cherry-picking release process?

I know you were asking Havard, but from my perspective it’s pretty good once you’re used to it. It makes keeping releases “clean" a lot easier. 

When do we want to do an actual release? Give me a date that suits you. Ideally, I’d let one of you do the actual release. We can try schedule a chat (irc / Skype / hangout / slack ) so I can talk one or both of you through it. 

Can you check that you have access to our Hudson instance (https://hudson.eclipse.org/rdf4j ) - you should have access once you have committer rights (use your Eclipse account e-mail and password to log in). Hudson is needed to build and deploy our maven artifacts to the central repository. Also check that you have SFTP access to build.eclipse.org, directory /home/data/httpd/download.eclipse.org/rdf4j . This is where the downloadable zip and onejar should be uploaded to. 

Jeen 

Back to the top