On 01/20/2014 06:39 AM, Karel Piwko wrote:
On Mon, 20 Jan 2014 12:27:22 +0100
Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
>
>>> +1 on postponing to a later point. If ready by April, should be fine as
>>> well (my opinion). Bruno had a good point, that the postponed release
>>> should not stop us from releasing (unstable) snapshots for testing
>> reasons.
>>> I like that: Release often, release early.
>> What is actually an (unstable) snapshot? Could you shed more light on that?
>>
> I'd say a regular snapshot, from master branch, released to the snapshot
> repo
That's good until another project(s) will rely on it. You update snaphot and
other projects will get broken without any option to avoid that. It would be
much better to make snapshots stable in time, as I described in previous email.
So
from my POV I don't mind code SNAPSHOTS always breaking. One of the
problems with having several machines and locations to work from is
keeping the code up to date. Because the Android project is in flux
based on upstream AND downstream projects (IE demos I'm writing to
exercise the APIs) it is very very nice to have something I can look at
and play with.
I understand a side effect of this is I will have to rewrite code, but
in my instance I'm usually rewriting code based on code changes I made.
Maybe we can do the Google thing and we have to rewrite tests we break?
(/me Waits for the flood of -1's)
>
>> Namely, is the "snapshot" a set of micro/minor releases of Aerogear
>> projects?
>> Or do you plan to release every Aerogear project as -SNAPSHOT? Or
>> introducing
>> -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into version
>> strings?
>>
>> I don't think 2/ option is a good idea, especially if SNAPSHOTs are
>> released
>> early & often. That would be a maintenance/testing nightmare, if various
>> SNAPSHOTs of the same project cannot be distinguished from each other and
>> used
>> within other projects.
>>
>> Karel
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev