[vfs] Minimal first release

[Stephen Colebourne <sc...@btopenworld.com>]

Simple question - can [vfs] be released *now*, with a minimal set of code?

I presume that the first release might thus consist only of the core 
plus standard java File and ram? No compress, ftp, http, ... I 
emphasise, think small.


Subsequent releases could then add these features in, and potentially 
provide the split jar files (if someone, eg a maven expert, wants to set 
up the multi jar solution)

Stephen

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

Re: Re: [vfs] Minimal first release

[Torsten Curdt <tc...@apache.org>]

> I know, you said (as I do) the jar-per-filesystem is the clean solution
> to go, but you also pointed out (as I do too ;-) ) the amount of work
> for each voter then.

Sorry, but are you guys seriously saying that the "work for each
voter" is too much? In the end this means "No, we cannot do 'release
early, release often' - too much work for the voters" ...for the
*voters*?

Come on guys!!

I have the same "issue" with jci then. But I think the modules do not
require to be a full-blown release of the core. (documentation, etc)
...they are modules and not to be used outside of the core.

So the burden I see is to actually to prepare the releases. But I have
my script that pretty much does a release with a few command lines.
(helps to have gpg-agent running)

 release checksum
 release checksum-verify
 release sign
 release sign-verify
 release stage
 release stage-verify

Then send out a mail to have people check the RC on people.apache.org.
After the voting I tag the release and do

 release live
 release live-verify
 release download

Everyone is wining about our huge release procedure - but it's only a
lot to do if you do all this by hand. (Why would you want to do that?)
My script is pretty stupid and would probably need to be adjusted to
work for all different projects ...but hell - I don't fear making
releases now anymore. So should no one else.

So let's do what makes most sense - not what seems less work.

My 2 cents

cheers
--
Torsten

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

Re: [vfs] Minimal first release

[Mario Ivankovits <ma...@ops.co.at>]

Hi Stephen!
>> Simple question - can [vfs] be released *now*, with a minimal set of
>> code?
I'd say, yes.

>> I presume that the first release might thus consist only of the core
>> plus standard java File and ram? No compress, ftp, http, ... I
>> emphasise, think small.
As Filip already pointed out, I too think for a user this release is not
much of help.
Based on Rahuls proposal I'd go to copy compress into VFSs codebase so
in the end we only miss
- smb
- webdav (Sorry Thorsten ;-) )

>> split jar files ..... if someone, eg a maven expert, wants to set
>> up the multi jar solution
I know, you said (as I do) the jar-per-filesystem is the clean solution
to go, but you also pointed out (as I do too ;-) ) the amount of work
for each voter then.
So when you talk about to setup a multi-jar-solution, do you mean the
jar-per-fs or the two-jar (vfs, sandbox) solution?


Ciao,
Mario


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

Re: [vfs] Minimal first release

[Rahul Akolkar <ra...@gmail.com>]

On 7/27/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Simple question - can [vfs] be released *now*, with a minimal set of code?
>
> I presume that the first release might thus consist only of the core
> plus standard java File and ram? No compress, ftp, http, ... I
> emphasise, think small.
>
>
> Subsequent releases could then add these features in, and potentially
> provide the split jar files (if someone, eg a maven expert, wants to set
> up the multi jar solution)
>
<snip/>

I believe the answer is yes, per Mario's proposal [1]. Looks good to me.

-Rahul

[1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=115399747722213&w=2


> Stephen
>

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

Re: [vfs] Minimal first release

[Filip Defoort <fi...@cirquedigital.com>]

This is just my 0.02$ as a VFS user: I don't think such a minimal release is
very useful as the primary reason for using VFS is for using it for more 
than
just a local FS. I think the suggest vfs/vfs-sandbox would work really well.

Cheers,
- Filip

Stephen Colebourne wrote:
> Simple question - can [vfs] be released *now*, with a minimal set of 
> code?
>
> I presume that the first release might thus consist only of the core 
> plus standard java File and ram? No compress, ftp, http, ... I 
> emphasise, think small.
>
>
> Subsequent releases could then add these features in, and potentially 
> provide the split jar files (if someone, eg a maven expert, wants to 
> set up the multi jar solution)
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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

Re: [vfs] Minimal first release

[Torsten Curdt <tc...@apache.org>]

> Subsequent releases could then add these features in, and potentially
> provide the split jar files (if someone, eg a maven expert, wants to set
> up the multi jar solution)

With jci we already have multi module project in the sandbox. So that
might help with the setup.

cheers
--
Torsten

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