Thanks for the great details, Bernd. Some questions/comments:
I hadn't even stumbled across VFS-570 due to its lack of fixVersion=2.1.
Are there more that need to be correctly tagged which could potentially
block the release of 2.1?
I'm not sure I follow you about the concern of using
maven-release-plugin with a multi-module maven project. This works just
fine (@see other Apache maven projects I'm involved in). If there are
demons laying in wait, I can knock them out as I find them.
Are there instructions on running clirr? I'm not familiar with the tool
(and I don't see any configuration in the top-level pom.xml).
Do you have the karma to make a 2.2 version on JIRA? That'd be a nice
help to start moving stuff out of 2.1 (as well as make sure things
sitting in Patch Available don't get forgotten). I would lean towards
the side of only putting bug-fixes into a 2.1.1 and preferring towards
any new features/changes into a 2.2 (to closer follow the definition of
semver). We presently have 3 major and 1 minor version unresolved for
fixVersion=2.1 -- these where the issues I previously referred to that I
felt OK bumping out as well.
Gary -- "BC breakage" == base-class breakage? As in: the common
base-class for all of the VFS Providers has changed (and would require
changes from anyone downstream that has built their own)?
I can try to start pounding on an initial RC in the evenings this week.
I'll be sure to reach out as I need some more help/karma ;)
Gary Gregory wrote:
Yes, there is a BC breakage for providers, is that grounds for a package
and Maven coordinate rename to vfs3?
Gary
On Tue, Apr 26, 2016 at 12:31 PM, Bernd Eckenfels<e...@zusammenkunft.net>
wrote:
Hello Josh,
I think a VFS 2.1 release would be cool and it is good that you
volunteer, so I dont object. My latest todo list is here:
https://wiki.apache.org/commons/VfsReleaseState
As you can see, I did plan to do the release and did quite some work to
get VFS into a releaseable state. But I am quite happy that you want to
step in as I havent had the time to do the procedure yet.
And this is not the actual release procedure (which should be doable as
long as you do not try to use the release-plugin and be careful about
the multi-module+sandbox nature of VFS (as opposed to other commons
projects)). Also be carefull about branch and tag namings (the SVN is a
bit messy in this regard).
My main concern I am afraid I would not have enough capacity is because
of the Clirr report and a lot of partially incompatible changes. Most
of them only affect providers if they do not properly use abstract base
classes, but still the list of Clirr violations is long and developers
here have not yet voiced if they would accept a RC with this situation
(or not).
Anyway, I do agree that the current critical and blocker bugs are
important but should not stop the 2.1 release (especially if a 2.1.1
release aferwards is much faster to do.) It would be cool to have
VFS-570 (write suport for VFS, but even that could be delivered with
2.1.1 - it might annoy the HDFS folks a bit)
So I can help you in case you need me to sponsor some changes (I hope I
have enough karma now).
We could even make a joined RC1, I am just not sure it wont open a big
chunk of additional work.
Gruss
Bernd
Am Tue, 26 Apr 2016 09:40:01 -0400
schrieb Josh Elser<els...@apache.org>:
Thanks Matt and Gary.
I do recall seeing the asf-wide note that my commit-bit also applies
to commons-*. Thanks for bringing that up. Specifically though, I am
only interested in cutting a release -- if we can get a new release
cut that we can use downstream, that increases the likelihood that I
will have more things to contribute back :)
I'll pull up the thread in the archives and get back to ya'll with
any questions I have after that.
- Josh
Matt Sicker wrote:
It's from the thread called "Whatever happened to commons-io 2.5?"
A few people stepped up to give the necessary permissions and
committed his GPG key.
On 25 April 2016 at 17:10, Gary Gregory<garydgreg...@gmail.com>
wrote:
Hi,
Agreed, VFS 2.1 has been too long in the making. We can release
ASAP without fixing more bugs IMO. RERO and all.
As an Apache committer, your are also an Apache Commons committer,
so feel free to create JIRAs, fix bugs and so on.
There might be some karma issues with a non-PMC member performing a
release, and I think we just went through this (sorry, I'm in
settling in a new house, not much time to dig in the ML archives).
Does anyone recall?
Gary
On Mon, Apr 25, 2016 at 12:06 PM, Josh Elser<els...@apache.org>
wrote:
Hi all,
There are presently 171 resolved issues sitting in commons-vfs2
2.1-SNAPSHOT, with 4 outstanding (none of which look like
blockers to
me).
The lack of any release of commons-vfs2 in years has been a big
problem downstream. This past weekend, I was again annoyed by
bugs that have been fixed (but not release) which is spurring me
to take some action. There have been emails reaching back as far
as 2014 asking when the next
release
might be, not to mention the fact that vfs-2.0 was released in
2011 (!).
History aside, I'm reaching out today to:
1) See if anyone on the PMC has the cycles to volunteer as RM.
1a) If not, how can you empower me (or others) to make the
release on your behalf.
2) Understand, specifically, what (if any) roadblocks exist to
release this version.
Thanks.
- Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition<http://www.manning.com/tahchiev/>
Spring Batch in Action<http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
