Hi Reto,

On Wed, Apr 23, 2014 at 4:38 PM, Reto Gmür <r...@wymiwyg.com> wrote:
> Hu Rupert,
>
> IMO before the first 1.0 release we need to address all major changes
>> that will break backward compatibility. From my side this would
>> include
>>
>> * Changes to the Enhancer API as suggested by STANBOL-1326 (see also
>> my mail from yesterday [1])
>> * Review/Change the Stanbol Enhancement Structure
>>     * with a look at standards like Open Annotation and NIF
>>     * and especially considering typical use cases
>>
>
> I'm very much welcome these changes but I think they can as well be part of
> a future release. The SNAPSHOT version has been there for a while and so I
> think it is justified to have a release that is actually compatible with
> what was built against this snapshot version. In an earlier discussion [2]
> I argued that it's an exaggeration to guarantee that no
> matter at which time you take a trunk snapshot version you will have a
> compatible release at some point, but in this case the trunk has been there
> for quite a while and software has been built against it. So we should imho
> follow the Release early, release often" mantra.
>

Is there actually a difference between 0.12 and 1.0.0? IMO every
application based on the 1.0.0-SNAPSHOT will run just fine with the
0.12 release. This is at least true for everyone using the RESTfull
services and for components implemented for the Enhancer (e.g.
EnhancementEngines) and the Entityhub (e.g. a Yard Implementation).

AFAIK the main difference between 0.12 and 1.0 is in the "REST layer"
(*.web and *.jersey modules). Exactly those changes where discussed in
[2], the creation of STANBOL-1094, implementation in a branch that
finally become the new trunk. The "compatible release" as mentions in
[2] was done based on on the old trunk (now the release-0.12 branch)
and the compatible release was 0.12.0 with 0.12.1 on the horizon (next
few weeks).

So when evaluating a release based on the trunk (1.0.0-SNAPSHOT) one
needs to focus on the progress of STANBOL-1094.

Even that all remaining Stanbol components to pass all tests since
some time there are still a lot of open things. Most important the
REST layer modules of all Stanbol components heavily depend on
deprecated APIs  such as WebFragment, Viewable, LinkResource and
ScriptResource. Honestly I do not even know how to change those
components to avoid using those APIs.

Just to give an example: Yesterday I tried to fix STANBOL-1329 by
registering the the SparqlMenuItem as OSGI service (Whiteboard pattern
as mentioned by STANBOL-1094) but it had not the expected effect of
the link being shown in the horizontal menu nor in the Stanbol main
page. Next I tried to find an example in one of the other components
defining menu Items but all of them where using the old way via the
WebFragment#getNavigationLinks(...).

What I am missing is a "migration guide" for STANBOL-1094. Maybe doing
all those changes would only require some days. But without knowing
how to do it I am not even able to start.

To be clear: I am fine with the API changes of using singleton
instances JAX-RS resources registered via the OSGI Whiteboard pattern
with the JAX-RS 2.0 implementation. I am just not convinced that
STANBOL-1094 and therefore 1.0.0 is ready to be release anytime soon.
I will not vote with +1 for a release based on the trunk as long as
the major part of the Stanbol components depend on the use of
deprecated APIs.

On Wed, Apr 23, 2014 at 4:38 PM, Reto Gmür <r...@wymiwyg.com> wrote:
>>
>> If we want to have an early release of the trunk version we could
>> consider to define milestone releases and assign the JIRA issues
>> accordingly. Not sure how such releases would play together with the
>> semantic versioning rules of OSGI.
>>
>
> We can choose version numbers as they fit. Even having a 2.0 release in the
> foreseable future wouldn't be a fundamental problem.

Making a 1.0 release that is mainly about STANBOL-1094 is fine for me.
Doing the Enhancer API changes (STANBOL-1326) and updates to the
Enhancement Structure in 2.0 is also fine with me. Maybe it is even
easier to grasp for users if 1.0 is still compatible with all the 0.*
releases and major changes are done with 2.0.

To go forward I would suggest:

* Reto, can you provide a migration guide - best in the description of
STANBOL-1094.
    * Reto can you port the Enhancer as an Example Component
    * I will make the necessary changes to the Entityhub
* Lets add a version 2.0.0 in JIRA and assign STANBOL-1326 as first issue to it.
    * I will also port the partial implementation of STANBOL-488 to
the trunk (as the complete one will only be available with 2.0.0)
    * I also changed STANBOL-351 to be part of   STANBOL-1326 -
meaning that the updates to the Enhancement Structure will be also
part of 2.0.0
* Adapt the release date for 1.0.0 to be much earlier (end of May?)
   * We should also create a 1.1 release so that we can assign issue
that we still want to do in 1.* but not for 1.0
   * We will need to go through all the issue and assign them to
1.0.0, 1.1.0 or 2.0.0

With this in place we should very fast an good overview what is needed
for a 1.0.0 release

WDYT
Rupert


>
>>
>> In addition there is still an open discussion about the Contenthub and
>> the CMS Adapter component. AFAIK @Rafa was investigating this. Could
>> someone provide more information on that.
>>
>
> There are always things than can be added and that can be improved, I don't
> see why this should be a blocker for releasing what we have.
>
>
>>
>> If we want to have an early release of the trunk version we could
>> consider to define milestone releases and assign the JIRA issues
>> accordingly. Not sure how such releases would play together with the
>> semantic versioning rules of OSGI.
>>
>
> We can choose version numbers as they fit. Even having a 2.0 release in the
> foreseable future wouldn't be a fundamental problem.
>
>
>>
>> BTW: I am currently working on the 0.12.1 release. As part of that I
>> have updated most of the OSGI, Sling and commonly used dependencies
>> (both for 0.12 and in trunk).
>>
>> As part of this work I also noticed the huge number of dependencies of
>> Jersey 2 in the trunk. With the update from 2.2 to 2.7 three
>> additional one where added (including a repacked version of Google
>> Guava with several MByte). @Reto: Does we still depend on using
>> jersey, or could we also consider other options for JAX-RS with 1.0
>>
> It should work with any JAX-RS 2.0 compatible implementation.
>
> Cheers,
> Reto
>
>
>>
>> best
>> Rupert
>>
>> [1] http://stanbol.markmail.org/thread/beexsyf2t62lavqz
>>
>
> 2.
> http://mail-archives.apache.org/mod_mbox/stanbol-dev/201211.mbox/%3ccalvhueuwvebtxgzj1q51-q6rx490s4antf8g15eykvpdh0t...@mail.gmail.com%3E
>
>>
>> >
>> > WDYT?
>> >
>> > Cheers,
>> > Reto
>> >
>> >
>> > 1. https://github.com/fusepool
>>
>>
>>
>> --
>> | Rupert Westenthaler             rupert.westentha...@gmail.com
>> | Bodenlehenstraße 11                              ++43-699-11108907
>> | A-5500 Bischofshofen
>> | 
>> REDLINK.CO..........................................................................
>> | http://redlink.co/
>>



-- 
| Rupert Westenthaler             rupert.westentha...@gmail.com
| Bodenlehenstraße 11                              ++43-699-11108907
| A-5500 Bischofshofen
| REDLINK.CO 
..........................................................................
| http://redlink.co/

Reply via email to