[jbosstools-dev] Fixing in both 4.3.x and master

[Max Rydahl Andersen]

> But according to Max's statistic report users don't care much if we 
> call our builds Alphas/Betas/CRs or GA/Final.

This is *not* what the statistic said.

I wrote:

"It does not seem to matter wether we call our release Alpha, Beta, CR 
or GA - users install our matching version when it is available for the 
eclipse version they move to."

This was given in context of ping backs from what gets installed.

Users install the jboss tools version that matches Eclipse GA, probably 
via eclipse marketplace.

This means GA is damn important - most users don't want to install jboss 
tools on Eclipse pre-GA.

What it does indicate though is that *users* does not seem to realise 
jboss tools is in alpha/beta/etc. If Eclipse is GA then they need 
whatever jboss tools has that matches.

But this ignores completely that we also have "users" like 
integration-stack that needs API stable releases.

The users also needs this, but they rarely notice it is an issue since 
we rebuild the core always so it works together and we somewhat tries to 
ensure we don't break workspace metadata support.

So please, do not translate that statistic into alpha/betas does not 
matter - the statistic implies that *more* Finals would probably be okey 
- users pick up our updates as they become available on the updatesite 
they have enabled.


More finals != do more milestones.

More Finals = more stable releases = more testing needed = more 
automation need.

> It means it doesn't make much sense to release 9.0.1.Final close to 
> 9.1.0.Beta.

It could be. Remember we have /stable and /development update sites to 
handle this.

When we release 9.1.0.Beta onto /development, the GA users won't get 
those fixes automatically.

A release to 9.0.1.Final is what would happen on /stable


I don't think we have done this kind of branching before, but it would 
be a sensible thing to do if we had the automated testing and automation 
in place.

> So, my proposal would be:
> 1. Plan to release 9.1.0.Beta1 in Xmas and 9.1.0.GA around Eclipse 
> Mars.2 (February/March 2016)
> 2. If we find any critical issue in 9.0.0.GA we want to fix earlier we 
> could release 9.0.1 in November.
>
> If it's OK I would move all current 9.0.1 issues to 9.1.0.Beta1. And 
> remove 9.0.1 not to confuse devs and QE. If we have any critical 
> issues and we see that we need release 9.0.1 then we will create this 
> version in JIRA.
>
> WDYT?

I would first outline the work we expect to go into it.

Call it 9.0.1 for now, do the rename (and possible branch) if/when 
needed.

Then there is no back pedalling of versions happening at osgi version. 
Only forward version jumps.

/max

> On 10/14/2015 03:06 PM, Fred Bricon wrote:
>> Can we rename 9.0.1.Beta1 to 9.1.0.Beta1 in JIRA, if need be?
>>
>> On Wed, Oct 14, 2015 at 2:29 PM, Alexey Kazakov <alkazako at redhat.com 
>> <mailto:alkazako at redhat.com>> wrote:
>>
>> 4.3.1.Beta1 yes.
>> 9.0.1.Beta1 probably yes too, but not sure we will release 9.0.1.
>> It's possible that we will release 9.1.0 Only. Anyway 9.1.0 will
>> use 4.3.x branch so, we can have both 9.0.1.Beta1 and 9.1.0.Beta1
>> and if we don't release 9.0.1 we will move all 9.0.1 issues to 9.1.0.
>>
>>
>> On 10/14/2015 02:22 PM, Denis Golovin wrote:
>>> Should we create specific development versions for 4.3.x/9.0.x
>>> streams in JIRA?
>>> Something like:
>>> - 4.3.1.Beta1
>>> - 9.0.1.Beta1
>>>
>>> Then we can use it in fixed issues.
>>>
>>> Currently I see only 4.3.1.Final and 9.0.1.GA <http://9.0.1.GA>
>>> are available.
>>>
>>> Denis
>>>
>>>
>>> On Fri, Oct 9, 2015 at 9:41 AM, Alexey Kazakov
>>> <alkazako at redhat.com <mailto:alkazako at redhat.com>> wrote:
>>>
>>>     Hi all,
>>>
>>>     Please make sure when you are fixing anything in both 4.3.x
>>>     and master
>>>     branches, create a separate issue for every stream. So we
>>>     will have two
>>>     JIRAs (the original one + a clone), one for 4.4.0 and the
>>>     second one for
>>>     4.3.0.
>>>     It will help QE to verify the issue is fixed in both streams.
>>>     Remember
>>>     we have different cycles for maintenance and main releases.
>>>     It's OK to have multiple fix versions in one JIRA while you
>>>     are working
>>>     on it. It's NOT OK to resolve an issue with the only fix
>>>     version and w/o
>>>     a clone while applying a PR to both streams!
>>>
>>>     Thanks.
>>>     _______________________________________________
>>>     jbosstools-dev mailing list
>>>     jbosstools-dev at lists.jboss.org
>>>     <mailto:jbosstools-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>>     --
>>>
>>>
>>>     CONFIDENTIALITY NOTICE: This email and files attached to it are
>>>     confidential. If you are not the intended recipient you are
>>>     hereby notified
>>>     that using, copying, distributing or taking any action in
>>>     reliance on the
>>>     contents of this information is strictly prohibited. If you
>>>     have received
>>>     this email in error please notify the sender and delete this
>>>     email.
>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email and files attached to it are
>>> confidential. If you are not the intended recipient you are
>>> hereby notified that using, copying, distributing or taking any
>>> action in reliance on the contents of this information is
>>> strictly prohibited. If you have received this email in error
>>> please notify the sender and delete this email.
>>>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org 
>> <mailto:jbosstools-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen