[jbosstools-dev] Why does update/kepler now point to Alpha2 ?

[Nick Boldt]

As we get better at *deploying* TPs w/o the SNAPSHOT suffix, then yes, 
we can differentiate between "won't change (AlphaX) " and "might change" 
(AlphaX-SNAPSHOT).

So yes, I could have called the new one Alpha2-SNAPSHOT instead of 
Alpha3-SNAPSHOT, but at the point where I was working on it, 
Alpha2-SNAPSHOT was "released" insofar as it was linked from here:

http://download.jboss.org/jbosstools/updates/kepler/compositeArtifacts.xml

Since that has now been changed to point to the last RELEASED TP, 
Alpha1, there's no reference to Alpha2 anymore and it's neither released 
nor referenced. It's essentially orphaned.

Anyway, it made sense to move to Alpha3 at the time. :)

On 03/25/2013 12:46 PM, Mickael Istria wrote:
> On 03/25/2013 05:32 PM, Nick Boldt wrote:
>> Then we should coordinate the changes better. Your addition of Jetty
>> (to Alpha2) happened a week before I started on the move to Kepler M6.
>> Had they all happened the same day, then yes, they would have all been
>> part of Alpha2.
>> But because there was a chance someone was using Alpha2 with the new
>> Jetty with Kepler M5, I didn't want to break them by suddenly changing
>> the underlying baseline.
>> The last time we had a workflow where contents of the target platform
>> could change "at random", to use Max's favourite phrase, Max
>> complained every time.
> In my understanding SNAPSHOT means "Work in Progress/nothing guaranteed"
> and includes that it can change more or less "at random". So we can make
> incremental changes on the target-platform.
> But that's only my understanding, maybe in our context it means
> something different.
> If we keep my definition of SNAPSHOT, the fact that Alpha2 has not been
> released means that we are free to change it.
> The general idea of a SNAPSHOT is that we won't be able to make the
> target-platform at first shot, it gives us the right to make mistakes
> that we can fix easily (by fixing and respinning this snapshot) and to
> make incremental changes, which will make the team happy as different
> requests for TP change happen multiple times during a dev stream.
>
>> Now, I version them explicitly so that every substantial commit is a
>> new version... and ya'll complain about that too.
> It's better ;) But I'm wondering about the usefulness of moving to
> Alpha3-SNAPSHOT when there is still an Alpha2 pending.
>
>> In the grand scheme of things, wouldn't you rather have snapshots you
>> can ignore (Alpha2, than snapshots that no longer exist because they
>> were overwritten?
> What is the benefit? This is going to lead us to have one version for
> each TP revision. We already have revisions to track atomic changes, I'm
> not sure we need something as fine-grained for public Maven versuins.
> Also, your proposal about more TP versions (with some ignored) will
> imply more maintenance effort to switch from a TP to another. We (ie you
> and me) won't like it.
>
>> IMHO it's *more confusing* if you're building one day with Alpha2 and
>> it works (because Kepler M5) and the next day it stops working
>> (because Kepler M6), than if you discover an email saying "want to use
>> Kepler M6? Grab the Alpha3 version of the target platform."
> If you're using one day Alpha2*-SNAPSHOT* and it works means that there
> will be some changes that may break you. So we make master use SNAPSHOT,
> and make changes on SNAPSHOT, and if we do something wrong, people will
> see it, us included.
> --
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets
> <http://twitter.com/mickaelistria>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com