You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2013/07/05 21:13:23 UTC
[ALL] Alpha releases - how to stop them becoming a dependency of a
released product
The thread about Collections Alpha release to Maven Central got me thinking.
So long as an Alpha release is only used for testing/local use, it
does not matter where it is published.
The problem comes if the Alpha release becomes a dependency of another
product which is then released.
So how do we stop that from happening?
Documentation helps, but some people ignore documentation.
Just wondering if it would be possible to incorporate some kind of
time-limit in the library, so that it stops working after a certain
date?
I've no idea if that is feasible - and it might cause too much of an
overhead - but perhaps worth investigating.
Obviously it would have to be well documented.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Alpha releases - how to stop them becoming a dependency
of a released product
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 05.07.2013 21:27, schrieb Paul Benedict:
> Don't try to solve how to stop an alpha release from becoming integrated.
> If someone does that, there's inherit risk involved. I don't see how this
> is any different, per se, a beta or RC release. If you build on unstable
> code, the only support advice I'd will get is: upgrade to the latest GA. :-)
>
IMHO we should lean towards innovation here rather than trying to
prevent possible problems with people doing stupid things. The term
"alpha release" should be well understood, so it should be obvious that
this release is not intended to be used in projects claiming to be ready
for production.
Oliver
>
> On Fri, Jul 5, 2013 at 2:13 PM, sebb <se...@gmail.com> wrote:
>
>> The thread about Collections Alpha release to Maven Central got me
>> thinking.
>>
>> So long as an Alpha release is only used for testing/local use, it
>> does not matter where it is published.
>>
>> The problem comes if the Alpha release becomes a dependency of another
>> product which is then released.
>>
>> So how do we stop that from happening?
>>
>> Documentation helps, but some people ignore documentation.
>>
>> Just wondering if it would be possible to incorporate some kind of
>> time-limit in the library, so that it stops working after a certain
>> date?
>>
>> I've no idea if that is feasible - and it might cause too much of an
>> overhead - but perhaps worth investigating.
>>
>> Obviously it would have to be well documented.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Alpha releases - how to stop them becoming a dependency of
a released product
Posted by Paul Benedict <pb...@apache.org>.
Don't try to solve how to stop an alpha release from becoming integrated.
If someone does that, there's inherit risk involved. I don't see how this
is any different, per se, a beta or RC release. If you build on unstable
code, the only support advice I'd will get is: upgrade to the latest GA. :-)
On Fri, Jul 5, 2013 at 2:13 PM, sebb <se...@gmail.com> wrote:
> The thread about Collections Alpha release to Maven Central got me
> thinking.
>
> So long as an Alpha release is only used for testing/local use, it
> does not matter where it is published.
>
> The problem comes if the Alpha release becomes a dependency of another
> product which is then released.
>
> So how do we stop that from happening?
>
> Documentation helps, but some people ignore documentation.
>
> Just wondering if it would be possible to incorporate some kind of
> time-limit in the library, so that it stops working after a certain
> date?
>
> I've no idea if that is feasible - and it might cause too much of an
> overhead - but perhaps worth investigating.
>
> Obviously it would have to be well documented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [ALL] Alpha releases - how to stop them becoming a dependency of
a released product
Posted by Gary Gregory <ga...@gmail.com>.
I really do not like the idea of putting a time-bomb in software,
especially coming from us!
This is not a problem for us to solve IMO.
All we need to decide is (1) whether we should release alphas and betas,
and if so, (2) where to release them.
After all, we do not prevent people from using Commons Lang 1.0.
Gary
On Fri, Jul 5, 2013 at 3:13 PM, sebb <se...@gmail.com> wrote:
> The thread about Collections Alpha release to Maven Central got me
> thinking.
>
> So long as an Alpha release is only used for testing/local use, it
> does not matter where it is published.
>
> The problem comes if the Alpha release becomes a dependency of another
> product which is then released.
>
> So how do we stop that from happening?
>
> Documentation helps, but some people ignore documentation.
>
> Just wondering if it would be possible to incorporate some kind of
> time-limit in the library, so that it stops working after a certain
> date?
>
> I've no idea if that is feasible - and it might cause too much of an
> overhead - but perhaps worth investigating.
>
> Obviously it would have to be well documented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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