You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2017/07/02 11:10:08 UTC
[MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Hi!
I'd like to do a Meecrowave release with owb-1.7.3 and then create a maintenance branch for the CDI-1.2 version in the next few days.
The alternative would be to create the maintenance branch _now_ and push for CDI-2.0 in trunk?
I honestly don't care, but we should all have the same understanding and clear communication about which way to go.
LieGrue,
strub
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Dear list, be my rubber duck :)
While hitting send I had another idea: Move the version before Romain's cdi2 upgrade to a mw_1.x branch and move trunk to 2.0.0-SNAPSHOT?
Would fit better to a clear product strategy imo. Wdyt?
LieGrue,
strub
> Am 02.07.2017 um 13:10 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>
> Hi!
>
> I'd like to do a Meecrowave release with owb-1.7.3 and then create a maintenance branch for the CDI-1.2 version in the next few days.
> The alternative would be to create the maintenance branch _now_ and push for CDI-2.0 in trunk?
>
> I honestly don't care, but we should all have the same understanding and clear communication about which way to go.
>
> LieGrue,
> strub
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
The api point was a ? for me since you should have meecrowave-core but get
the portable approach - guess it is what you mean - which is valid.
+1 for trunk = 2 snapshot and a 1.x branch
Le 2 juil. 2017 13:50, "Mark Struberg" <st...@yahoo.de.invalid> a écrit :
> The other point why I'd prefer mw-1.x and 2.x is that 0.x versions often
> get interpreted as 'not production ready'
>
> Of course we would also go with 1.0.0 for the release with owb-1.7.3 and
> upgrade to owb-2.0.0 for 1.1.x and later?
>
> LieGrue,
> strub
>
>
> > Am 02.07.2017 um 13:37 schrieb Mark Struberg <struberg@yahoo.de.INVALID
> >:
> >
> > People have e.g. geronimo-jcdi_1.1_spec.jar as <scope>provided in their
> pom.
> > So when they use the meecrowave test runner this might clash with the
> geronimo-jcdi_2.0 classpath.
> >
> > Thus people MUST upgrade their dependencies as well.
> >
> > LieGrue,
> > strub
> >
> >> Am 02.07.2017 um 13:33 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> >>
> >> Le 2 juil. 2017 13:21, "Mark Struberg" <st...@yahoo.de.invalid> a
> écrit :
> >>
> >> Here is my take on it:
> >> We should make ALL API changes at least a minor version bump.
> >> Moving from JSON-P 1.0 to 1.1 from mw-0.3.0 to 0.3.1 was imo not the
> best
> >> idea.
> >> We should do better in the future.
> >>
> >> The problem is that every project which uses Meecrowave would also need
> to
> >> update their internal APIs, otherwise they'll get dirty class compat
> >> issues. So people MUST be aware that an API did change.
> >>
> >>
> >>
> >> Is that true? If it does occur for something not being an addition or
> being
> >> an ee spec change then we have a big trouble (= shouldnt occur by
> design so
> >> should be ok to do any time).
> >>
> >> We can discuss changing the version to reflect it in another thread but
> it
> >> is still minor in term of impact for meecrowave users.
> >>
> >> One gain of meecrowave is to not be tied to ee constraint and get more
> >> freedom on upgrades so if we need to add back this constraint we get a
> lot
> >> more maintenance load for pretty much no end user gain IMHO. This is
> what
> >> id like to avoid.
> >>
> >> What are the thing justifying to not upgrade? Can you list the use
> cases?
> >>
> >>
> >> This might be mitigated if we would provide a merged meecrowave-api.jar
> >> which contains all the geronimo-spec + tomcat-api jars we use.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 02.07.2017 um 13:14 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com>:
> >>>
> >>> I like keeping trunk work and therefore create the maintenance now
> between
> >>> the 2 options.
> >>>
> >>> Now i dont see why we would need to be stuck on a cdi version. Same as
> we
> >>> upgraded from jsonp 1 to 1.1 we can upgrade to cdi 2 directly imo
> since it
> >>> shouldnt break anything.
> >>>
> >>> Goal would be to not impact the users, give them more api and feature
> and
> >>> keep a single branch for us.
> >>>
> >>> Anything making this reasoning wrong?
> >>>
> >>>
> >>>
> >>>
> >>> Le 2 juil. 2017 13:10, "Mark Struberg" <st...@yahoo.de.invalid> a
> >> écrit :
> >>>
> >>> Hi!
> >>>
> >>> I'd like to do a Meecrowave release with owb-1.7.3 and then create a
> >>> maintenance branch for the CDI-1.2 version in the next few days.
> >>> The alternative would be to create the maintenance branch _now_ and
> push
> >>> for CDI-2.0 in trunk?
> >>>
> >>> I honestly don't care, but we should all have the same understanding
> and
> >>> clear communication about which way to go.
> >>>
> >>> LieGrue,
> >>> strub
> >
>
>
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
The other point why I'd prefer mw-1.x and 2.x is that 0.x versions often get interpreted as 'not production ready'
Of course we would also go with 1.0.0 for the release with owb-1.7.3 and upgrade to owb-2.0.0 for 1.1.x and later?
LieGrue,
strub
> Am 02.07.2017 um 13:37 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
>
> People have e.g. geronimo-jcdi_1.1_spec.jar as <scope>provided in their pom.
> So when they use the meecrowave test runner this might clash with the geronimo-jcdi_2.0 classpath.
>
> Thus people MUST upgrade their dependencies as well.
>
> LieGrue,
> strub
>
>> Am 02.07.2017 um 13:33 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>
>> Le 2 juil. 2017 13:21, "Mark Struberg" <st...@yahoo.de.invalid> a écrit :
>>
>> Here is my take on it:
>> We should make ALL API changes at least a minor version bump.
>> Moving from JSON-P 1.0 to 1.1 from mw-0.3.0 to 0.3.1 was imo not the best
>> idea.
>> We should do better in the future.
>>
>> The problem is that every project which uses Meecrowave would also need to
>> update their internal APIs, otherwise they'll get dirty class compat
>> issues. So people MUST be aware that an API did change.
>>
>>
>>
>> Is that true? If it does occur for something not being an addition or being
>> an ee spec change then we have a big trouble (= shouldnt occur by design so
>> should be ok to do any time).
>>
>> We can discuss changing the version to reflect it in another thread but it
>> is still minor in term of impact for meecrowave users.
>>
>> One gain of meecrowave is to not be tied to ee constraint and get more
>> freedom on upgrades so if we need to add back this constraint we get a lot
>> more maintenance load for pretty much no end user gain IMHO. This is what
>> id like to avoid.
>>
>> What are the thing justifying to not upgrade? Can you list the use cases?
>>
>>
>> This might be mitigated if we would provide a merged meecrowave-api.jar
>> which contains all the geronimo-spec + tomcat-api jars we use.
>>
>> LieGrue,
>> strub
>>
>>> Am 02.07.2017 um 13:14 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>>
>>> I like keeping trunk work and therefore create the maintenance now between
>>> the 2 options.
>>>
>>> Now i dont see why we would need to be stuck on a cdi version. Same as we
>>> upgraded from jsonp 1 to 1.1 we can upgrade to cdi 2 directly imo since it
>>> shouldnt break anything.
>>>
>>> Goal would be to not impact the users, give them more api and feature and
>>> keep a single branch for us.
>>>
>>> Anything making this reasoning wrong?
>>>
>>>
>>>
>>>
>>> Le 2 juil. 2017 13:10, "Mark Struberg" <st...@yahoo.de.invalid> a
>> écrit :
>>>
>>> Hi!
>>>
>>> I'd like to do a Meecrowave release with owb-1.7.3 and then create a
>>> maintenance branch for the CDI-1.2 version in the next few days.
>>> The alternative would be to create the maintenance branch _now_ and push
>>> for CDI-2.0 in trunk?
>>>
>>> I honestly don't care, but we should all have the same understanding and
>>> clear communication about which way to go.
>>>
>>> LieGrue,
>>> strub
>
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
People have e.g. geronimo-jcdi_1.1_spec.jar as <scope>provided in their pom.
So when they use the meecrowave test runner this might clash with the geronimo-jcdi_2.0 classpath.
Thus people MUST upgrade their dependencies as well.
LieGrue,
strub
> Am 02.07.2017 um 13:33 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Le 2 juil. 2017 13:21, "Mark Struberg" <st...@yahoo.de.invalid> a écrit :
>
> Here is my take on it:
> We should make ALL API changes at least a minor version bump.
> Moving from JSON-P 1.0 to 1.1 from mw-0.3.0 to 0.3.1 was imo not the best
> idea.
> We should do better in the future.
>
> The problem is that every project which uses Meecrowave would also need to
> update their internal APIs, otherwise they'll get dirty class compat
> issues. So people MUST be aware that an API did change.
>
>
>
> Is that true? If it does occur for something not being an addition or being
> an ee spec change then we have a big trouble (= shouldnt occur by design so
> should be ok to do any time).
>
> We can discuss changing the version to reflect it in another thread but it
> is still minor in term of impact for meecrowave users.
>
> One gain of meecrowave is to not be tied to ee constraint and get more
> freedom on upgrades so if we need to add back this constraint we get a lot
> more maintenance load for pretty much no end user gain IMHO. This is what
> id like to avoid.
>
> What are the thing justifying to not upgrade? Can you list the use cases?
>
>
> This might be mitigated if we would provide a merged meecrowave-api.jar
> which contains all the geronimo-spec + tomcat-api jars we use.
>
> LieGrue,
> strub
>
>> Am 02.07.2017 um 13:14 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>>
>> I like keeping trunk work and therefore create the maintenance now between
>> the 2 options.
>>
>> Now i dont see why we would need to be stuck on a cdi version. Same as we
>> upgraded from jsonp 1 to 1.1 we can upgrade to cdi 2 directly imo since it
>> shouldnt break anything.
>>
>> Goal would be to not impact the users, give them more api and feature and
>> keep a single branch for us.
>>
>> Anything making this reasoning wrong?
>>
>>
>>
>>
>> Le 2 juil. 2017 13:10, "Mark Struberg" <st...@yahoo.de.invalid> a
> écrit :
>>
>> Hi!
>>
>> I'd like to do a Meecrowave release with owb-1.7.3 and then create a
>> maintenance branch for the CDI-1.2 version in the next few days.
>> The alternative would be to create the maintenance branch _now_ and push
>> for CDI-2.0 in trunk?
>>
>> I honestly don't care, but we should all have the same understanding and
>> clear communication about which way to go.
>>
>> LieGrue,
>> strub
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 2 juil. 2017 13:21, "Mark Struberg" <st...@yahoo.de.invalid> a écrit :
Here is my take on it:
We should make ALL API changes at least a minor version bump.
Moving from JSON-P 1.0 to 1.1 from mw-0.3.0 to 0.3.1 was imo not the best
idea.
We should do better in the future.
The problem is that every project which uses Meecrowave would also need to
update their internal APIs, otherwise they'll get dirty class compat
issues. So people MUST be aware that an API did change.
Is that true? If it does occur for something not being an addition or being
an ee spec change then we have a big trouble (= shouldnt occur by design so
should be ok to do any time).
We can discuss changing the version to reflect it in another thread but it
is still minor in term of impact for meecrowave users.
One gain of meecrowave is to not be tied to ee constraint and get more
freedom on upgrades so if we need to add back this constraint we get a lot
more maintenance load for pretty much no end user gain IMHO. This is what
id like to avoid.
What are the thing justifying to not upgrade? Can you list the use cases?
This might be mitigated if we would provide a merged meecrowave-api.jar
which contains all the geronimo-spec + tomcat-api jars we use.
LieGrue,
strub
> Am 02.07.2017 um 13:14 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> I like keeping trunk work and therefore create the maintenance now between
> the 2 options.
>
> Now i dont see why we would need to be stuck on a cdi version. Same as we
> upgraded from jsonp 1 to 1.1 we can upgrade to cdi 2 directly imo since it
> shouldnt break anything.
>
> Goal would be to not impact the users, give them more api and feature and
> keep a single branch for us.
>
> Anything making this reasoning wrong?
>
>
>
>
> Le 2 juil. 2017 13:10, "Mark Struberg" <st...@yahoo.de.invalid> a
écrit :
>
> Hi!
>
> I'd like to do a Meecrowave release with owb-1.7.3 and then create a
> maintenance branch for the CDI-1.2 version in the next few days.
> The alternative would be to create the maintenance branch _now_ and push
> for CDI-2.0 in trunk?
>
> I honestly don't care, but we should all have the same understanding and
> clear communication about which way to go.
>
> LieGrue,
> strub
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Here is my take on it:
We should make ALL API changes at least a minor version bump.
Moving from JSON-P 1.0 to 1.1 from mw-0.3.0 to 0.3.1 was imo not the best idea.
We should do better in the future.
The problem is that every project which uses Meecrowave would also need to update their internal APIs, otherwise they'll get dirty class compat issues. So people MUST be aware that an API did change.
This might be mitigated if we would provide a merged meecrowave-api.jar which contains all the geronimo-spec + tomcat-api jars we use.
LieGrue,
strub
> Am 02.07.2017 um 13:14 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> I like keeping trunk work and therefore create the maintenance now between
> the 2 options.
>
> Now i dont see why we would need to be stuck on a cdi version. Same as we
> upgraded from jsonp 1 to 1.1 we can upgrade to cdi 2 directly imo since it
> shouldnt break anything.
>
> Goal would be to not impact the users, give them more api and feature and
> keep a single branch for us.
>
> Anything making this reasoning wrong?
>
>
>
>
> Le 2 juil. 2017 13:10, "Mark Struberg" <st...@yahoo.de.invalid> a écrit :
>
> Hi!
>
> I'd like to do a Meecrowave release with owb-1.7.3 and then create a
> maintenance branch for the CDI-1.2 version in the next few days.
> The alternative would be to create the maintenance branch _now_ and push
> for CDI-2.0 in trunk?
>
> I honestly don't care, but we should all have the same understanding and
> clear communication about which way to go.
>
> LieGrue,
> strub
Re: [MEECROWAVE] Next release and timeframe to upgrade to OWB-2?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I like keeping trunk work and therefore create the maintenance now between
the 2 options.
Now i dont see why we would need to be stuck on a cdi version. Same as we
upgraded from jsonp 1 to 1.1 we can upgrade to cdi 2 directly imo since it
shouldnt break anything.
Goal would be to not impact the users, give them more api and feature and
keep a single branch for us.
Anything making this reasoning wrong?
Le 2 juil. 2017 13:10, "Mark Struberg" <st...@yahoo.de.invalid> a écrit :
Hi!
I'd like to do a Meecrowave release with owb-1.7.3 and then create a
maintenance branch for the CDI-1.2 version in the next few days.
The alternative would be to create the maintenance branch _now_ and push
for CDI-2.0 in trunk?
I honestly don't care, but we should all have the same understanding and
clear communication about which way to go.
LieGrue,
strub