3:03 a.m.
Just since it seems a few key points about locus seem forgotten here are a few reminders:
Locus is *not* an updatesite to use in a way that exposes it to users - it is to be used
to be included in other updatesites.
We used nexus to publish Locus so we can gather experience to use just pure mvn deploy,
meaning:
a) no need for maintaining external buld scripts for publishing
b) stop/reduce the amount needed for publishing (being able to have others than a few
people do these releases)
c) stop hiding or allowing "I can just edit the produced content manually on the
running server"
About C - if the html is so often wrong these needs to change then that should simply not
be included in the published updatesite zip;
or we simply do a basic respin to fix it - everything is tracked in git as opposed to
"change it live on the server".
I think doing a basic 1.1.1.Final (or even just 1.1.0.Final) with the current locus setup
is a trivial excercise compared to any manual
edits and tweaking which then gets lots for next time we build it.
/max
On Wed, Oct 23, 2013 at 12:04:27AM -0400, Max Andersen wrote:
Guys,
Just do a 1.1.1.Final and get it over with.
It really shouldn't be this long to get done. That is the same as doing the mirroring
and done much faster.
It's just a quick update to fix minor issue for consistency.
1.2.0.Final makes no sense since we didn't change anything functionality wise.
1.1.0.1.Final is just as borked to use as 1.1.0.
And "lets just change the index html straight on apache" is pointless since that
is just continue doing things in a way that can't be reproduced easily and hides the
actual changes (no matter how small)
/max
/max (sent from my phone)
> On 22/10/2013, at 20.43, Rob Cernich <rcernich(a)redhat.com> wrote:
>
> Maybe I've missed something in this whole discussion, but isn't a version of
Locus simply a collection of specific versions of various OSGi-fied plugins? If so, a
version of Locus is simply a version in a pom (that creates Locus), a tag in source
control, some text in a p2 repository and a path segment in a URL. If it is that simple,
can't we just mirror what's already out there to a different folder and everybody
can simply update their Locus references to point to the new URL?
>
> ----- Original Message -----
>> Since the change we're proposing is really a non-change (just cosmetic
>> alterations), why not 1.1.1.Final (maintenance) or even 1.1.0.1.Final
>> (trivial maintenance)?
>>
>> 1.2.0 suggests "we actually did something new" not "due to the
limits of
>> Nexus / Maven we are required to bump the version simply to adhere to
>> versioning conventions that state we should have '.Final' as the
>> qualifier on a release even though there's no actual IU in the site
>> which contains this version, so it's entirely just a label".
>>
>> The more I think about this, the more the idea of having to respin
>> simply for a cosmetic alteration seems pointless. Bumping the version
>> means I'll have to push new bits onto download.jboss.org AND JBTIS will
>> have to (again) update their TP references in order to pull down *the
>> identical bits*. That's a lot of cascading work for a purely cosmetic
>> change.
>>
>> So, other than the fact that the site doesn't have .Final in Nexus, and
>> it says "Nightly" instead of "Stable", do we *REALLY* need to
bother?
>>
>> Surely these are trivial problems we can fix in concert with some ACTUAL
>> fixes or new content in Locus, for the 1.2 release in the far-flung future.
>>
>> WDYT?
>>
>>> On 10/22/2013 10:59 AM, Mickael Istria wrote:
>>>> On 10/22/2013 03:32 PM, Nick Boldt wrote:
>>>> -1 for fake commits just to bump the timestamp. A rebuild should
>>>> change nothing but the build ID (build timestamp + build number).
>>> I'm ok with that.
>>>> +1 for re-releasing the bits as 1.1.0.Final, with the corrected
>>>> index.html ("Stable Release" not "Nightly Build")
>>> What about 1.2.0.Final? I've already made 1.2.0-SNAPSHOT follow 1.1.0 so
>>> 1.2.0.Final would be easier.
>>> --
>>> 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
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev