commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <e...@zusammenkunft.net>
Subject [VFS] Release Preparations 2.1 (again)
Date Tue, 02 Dec 2014 22:51:09 GMT
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
<ralph.goers@dslextreme.com>:

> 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
> http://wiki.apache.org/logging/Log4j2ReleaseGuide
> <http://wiki.apache.org/logging/Log4j2ReleaseGuide>, 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: 
http://people.apache.org/~ecki/commons-vfs/commons-vfs2/clirr-report.html
)


Greetings
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message