Snapshots are unstable by definition, period. If necessary release anything for testing
will be necessary, well this was supposed to be done after we reach a consensus at
whatever feature.
--
abstractj
On January 20, 2014 at 12:07:44 PM, Summers Pittman (supittma(a)redhat.com) wrote:
On 01/20/2014 06:39 AM, Karel Piwko wrote:
> On Mon, 20 Jan 2014 12:27:22 +0100
> Matthias Wessendorf wrote:
>
>> On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko
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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev