Re: Launchpad stable and launchpad unstable

[Robert Munteanu <ro...@apache.org>]

On Mon, 2016-10-31 at 11:17 +0100, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote
> > On Wed, Oct 26, 2016 at 9:08 AM, Robert Munteanu <rombert@apache.or
> > g> wrote:
> > > ...How would we handle launchpad tests that rely on functionality
> > > introduced in a SNAPSHOT dependency?...
> > 
> > I suppose we'll need an annotation to indicate the requirements for
> > a
> > specific test.
> > 
> 
> Isn't that a little bit complicated? Who removes the annotation when
> things are released?

How about an annotation or an assumption mechanism which looks for a
specific bundle + version to be present? That would not need further
maintenance and can be removed at any time, should we want to remove
it:

  @NeedsBundle("org.apache.sling.commons.json", "2.1.0")
  @Test
  public void validateSomething() { ... }

or

  @Test
  public void validateSomething() {
    assumeThat(bundleIsPresent("org.apache.sling.commons.json",
"2.1.0"));
    ...
  }

> 
> In general, can we come up with a full proposal instead of discussing
> individual single points? I suggest we setup a wiki where we outline
> the
> full process and then can fill in the details

I can come up with a full proposal but there are some things which are
not totally clear to me, so that's why I'm asking :-)

Robert

Re: Launchpad stable and launchpad unstable

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Nov 1, 2016 at 10:08 AM, Robert Munteanu <ro...@apache.org> wrote:
...
>   @NeedsBundle("org.apache.sling.commons.json", "2.1.0")
...
>     assumeThat(bundleIsPresent("org.apache.sling.commons.json",
...

I like the idea, maybe with names like @NeedsBundleVersion and
bundleVersionPresent(...) to be more explicit.

Maybe we need something similar for package versions, but the
mechanism will be similar.

-Bertrand

Re: Launchpad stable and launchpad unstable

[Robert Munteanu <ro...@apache.org>]

On Wed, 2016-11-02 at 12:02 +0100, Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote
> > On Wed, Nov 2, 2016 at 9:39 AM, Carsten Ziegeler <cziegeler@apache.
> > org> wrote:
> > > Bertrand Delacretaz wrote
> > > > On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler <cziegeler@apa
> > > > che.org> wrote:
> > > > > ...what problem are we exactly trying to solve?
> > > > 
> > > > ...As described in the original post here - having a stable
> > > > launchpad
> > > > that's always ready to release, while also continuously testing
> > > > the
> > > > integration of the latest snapshots.
> > > > 
> > > 
> > > So if the integration tests always test the latest snapshots then
> > > there
> > > is nothing we have do to, right?...
> > 
> > We need to test the launchpad that we release, don't we?
> 
> Yeah, sorry that I'm a little bit picky here. All I'm trying that we
> get
> a description of the full picture.
> 
> We want to test the *same* integration tests against the current
> launchpad (which has no snapshot deps) and against the same launchpad
> but replacing all sling deps to the latest snapshot versions.
> And that might lead us into the situation you describe below.
> 
> > 
> > Depending on the combination of bundles that release might have
> > different behavior than combining the latest snapshots, although
> > maybe
> > it's not that likely.
> 
> Right, I would argue that it is not very likely.
> 
> > 
> > As a first step we might manually run the integration tests against
> > the launchpad that's about to be released, that's better than
> > nothing
> > but some tests will fail and we need a manual analysis of that -
> > which
> > is not impossible if the goal is to release say every 3 months.
> 
> Instead of coming up with a gigantic approach that will not be used
> or
> only once every two years, I think lets deal with it once we're
> there.
> Something simple like an exclusion list activated by the same
> mechanism
> that switches to snapshot dependencies.

I've tried to summarise the current state of the discussions at 

  https://cwiki.apache.org/confluence/display/SLING/Moving+the+Sling+La
unchpad+to+use+released+artifacts+only

I think currently we need to decide/finalise:

- how to transform a 'stable' launchpad into an 'unstable' one
- how to exclude tests from running on an 'stable' launchpad but keep
the running on an 'unstable' launchpad.

Comment on the wiki page more than welcome, I have probably missed
something :-)

Thanks,

Robert 
> 
> �Carsten
> 

Re: Launchpad stable and launchpad unstable

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote
> On Wed, Nov 2, 2016 at 9:39 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Bertrand Delacretaz wrote
>>> On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>> ...what problem are we exactly trying to solve?
>>> ...As described in the original post here - having a stable launchpad
>>> that's always ready to release, while also continuously testing the
>>> integration of the latest snapshots.
>>>
>> So if the integration tests always test the latest snapshots then there
>> is nothing we have do to, right?...
> 
> We need to test the launchpad that we release, don't we?

Yeah, sorry that I'm a little bit picky here. All I'm trying that we get
a description of the full picture.

We want to test the *same* integration tests against the current
launchpad (which has no snapshot deps) and against the same launchpad
but replacing all sling deps to the latest snapshot versions.
And that might lead us into the situation you describe below.

> 
> Depending on the combination of bundles that release might have
> different behavior than combining the latest snapshots, although maybe
> it's not that likely.

Right, I would argue that it is not very likely.

> 
> As a first step we might manually run the integration tests against
> the launchpad that's about to be released, that's better than nothing
> but some tests will fail and we need a manual analysis of that - which
> is not impossible if the goal is to release say every 3 months.

Instead of coming up with a gigantic approach that will not be used or
only once every two years, I think lets deal with it once we're there.
Something simple like an exclusion list activated by the same mechanism
that switches to snapshot dependencies.

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: Launchpad stable and launchpad unstable

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Nov 2, 2016 at 9:39 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Bertrand Delacretaz wrote
>> On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> ...what problem are we exactly trying to solve?
>> ...As described in the original post here - having a stable launchpad
>> that's always ready to release, while also continuously testing the
>> integration of the latest snapshots.
>>
> So if the integration tests always test the latest snapshots then there
> is nothing we have do to, right?...

We need to test the launchpad that we release, don't we?

Depending on the combination of bundles that release might have
different behavior than combining the latest snapshots, although maybe
it's not that likely.

As a first step we might manually run the integration tests against
the launchpad that's about to be released, that's better than nothing
but some tests will fail and we need a manual analysis of that - which
is not impossible if the goal is to release say every 3 months.

-Bertrand

Re: Launchpad stable and launchpad unstable

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote
> On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...what problem are we exactly trying to solve?
> 
> As described in the original post here - having a stable launchpad
> that's always ready to release, while also continuously testing the
> integration of the latest snapshots.
> 
So if the integration tests always test the latest snapshots then there
is nothing we have do to, right?

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: Launchpad stable and launchpad unstable

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...what problem are we exactly trying to solve?

As described in the original post here - having a stable launchpad
that's always ready to release, while also continuously testing the
integration of the latest snapshots.

-Bertrand

Re: Launchpad stable and launchpad unstable

[Carsten Ziegeler <cz...@apache.org>]

Maybe I'm missing something, but what problem are we exactly trying to
solve?

Carsten


Robert Munteanu wrote
> On Mon, 2016-10-31 at 11:17 +0100, Carsten Ziegeler wrote:
>> Bertrand Delacretaz wrote
>>> On Wed, Oct 26, 2016 at 9:08 AM, Robert Munteanu <rombert@apache.or
>>> g> wrote:
>>>> ...How would we handle launchpad tests that rely on functionality
>>>> introduced in a SNAPSHOT dependency?...
>>>
>>> I suppose we'll need an annotation to indicate the requirements for
>>> a
>>> specific test.
>>>
>>
>> Isn't that a little bit complicated? Who removes the annotation when
>> things are released?
> 
> How about an annotation or an assumption mechanism which looks for a
> specific bundle + version to be present? That would not need further
> maintenance and can be removed at any time, should we want to remove
> it:
> 
>   @NeedsBundle("org.apache.sling.commons.json", "2.1.0")
>   @Test
>   public void validateSomething() { ... }
> 
> or
> 
>   @Test
>   public void validateSomething() {
>     assumeThat(bundleIsPresent("org.apache.sling.commons.json",
> "2.1.0"));
>     ...
>   }
> 
>>
>> In general, can we come up with a full proposal instead of discussing
>> individual single points? I suggest we setup a wiki where we outline
>> the
>> full process and then can fill in the details
> 
> I can come up with a full proposal but there are some things which are
> not totally clear to me, so that's why I'm asking :-)
> 
> Robert
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org