commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex <>
Subject Re: [VFS] Release Preparations 2.1 (again)
Date Tue, 02 Dec 2014 22:55:40 GMT
Is there a chance to get VFS-180 in 2.1?

On 03/12/14 01:51, Bernd Eckenfels wrote:
> Hello,
> ok, lets start another try to get VFS released. (and refresh my
> memories who is volunteering for the RM? - I would do it but I think we
> need a PMC at close hand).
> Currently are 3 open blocker bugs, for one I have a patch pending, the
> other two I am inclined to downgrade when nobody takes care of
> them: They affect only a specific usecase, I am not sure if they are
> regressions at all (I dont want to discourage anybody to solve them,
> but I will not invest time before the release).
> I am not so familiar with all of the Release Process, so I hope
> somebody will help me, preferable from the PMC?
> Ralph summarized, what he remebers is needed, I want to comment on
> it:
>   Am Sat, 29 Nov 2014 19:54:42 -0700 schrieb Ralph Goers
> <>:
>> I acted as release manager for 2.0.  I did that because at the time I
>> had a need for Commons VFS, I had a need to fix a bunch of stuff that
>> didn’t work in 1.0, and I had the necessary privileges to do it.
>> Since that time I have been focused on Log4j 2 almost completely with
>> what little time I have.  I have seen others commit fixes and
>> enhancements and like you, I have been surprised that no one has
>> bothered to perform a release. It should have happened a long time
>> ago.
>> One challenge to releasing VFS is that unlike most Commons projects,
>> it is a multi-module project and it uses the Maven release plugin to
>> perform a release. While this makes things a bit more complicated it
>> still isn’t that hard to do.
> Actually so much time has passed, that it does no longer look hard for
> you. But when I look at the svn, I see no RC tags, a 2.0 tag which
> does not fit the 1.0 naming conventions, I see 12 tries to actually
> release the project (and quite a few rollbacks or tag copies). I would
> not call this "not hard". But I do agree, your writeup helps, and it
> should be possible (at least with PMC help). I tried to follow the
> release tries in the archives, thats helpfull too.
>> Unfortunately, I don’t believe I
>> documented the release process but it should be similar to
>> <>, since I based
>> the Log4j build and release process after VFS.
> Before we do this, a couple of questions:
> - how hard is it to delete tags from SVN and who can do that? I know
>    from experience with the release plugin that you typically need to
>    delete the tag multiple times to get things right. So it would be
>    good if somebody is available to do that on demand. And will we
>    actually tag each RC with the release version and modify this, or
>    will we have RC tags in the pom and
> - do we maven-release RCs with the plugin? Is it ok if I cut the first
>    RC myself? Ralph used Nexus staging. Can I get access to one which
>    is set up for commons, or should a ask INFRA to prepare one?
> - I haven't found requirements (besides commiter-owned) on the build
>    environment, do we use OpenJDK or OracleJDK. Is Windows acceptable?
>    (I think we are talking Java 6 here)
> - is a 3kbit key fine for code signing?
> - I would actually prefer to release before moving jcifs into core. If
>    somebody wants to see it released with 2.1, then please provide a
>    patch. I think the only solution would be a default-off profile with
>    an optional LPGL dinary nor source will pull in this dependency by
>    default.
> - I would not care for Java 8 compile. Or actually: yes it compiles but
>    the site built might not completely work.
> In parallel to that I will start a discussion on the Clirr report. I
> did that in the past and I will make a spreadsheet so we can work
> sharedly on marking things as reviewed or critical.
> (the last time i tried to discuss it, I had uploaded:
> )
> Greetings
> Bernd
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

/--Regards, Alex/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message