Of course we could only apply this scheme to dev releases only and
keep a stable version for major releases. But what if a change for 5.0.1 breaks something
for 5.0.0 users?
By definition that should not happen. Backwards compatible and all.
/max
As usual it's either more safety == more maintenance vs more
flexbility == more risks
Le 19/01/2012 09:28, Max Rydahl Andersen a écrit :
>> Sorry for the hiccup,
>>
>> Well this is not a svn/publishing issue IMHO (I triggered the publishing job
manually)
> aah - good and bad to hear ;) good that it wasn't automated and bad to hear it
was manually triggered.
>
>> what we really need to do is use separate descriptors for different released
versions. This is already the case for JBT (where
http://anonsvn.jboss.org/repos/jbosstools/trunk/download.jboss.org/jbosst...
is pretty safe), but not for JBDS, and that went bad.
> for dev releases - yeah this makes sense, but what when we go for maintanence then
the intent is that these should not be named differently as otherwise those on 5.0.0
won't see changes done for 5.0.1 and vice versa.
>
> /max
>
>> Regards,
>>
>> Fred Bricon
>>
>> Le 18/01/2012 14:50, Max Rydahl Andersen a écrit :
>>> Hi,
>>>
>>> Today Fred was experimenting with changing project examples for some
improvements in B1.
>>>
>>> That included renaming some categories which he changed, committed to svn
trunk and then later today
>>> I got 1,2,3 and now 4 mails about examples being broken in M5.
>>>
>>> Why ?
>>> Because we have some automatic update script running that takes whatever is
latest in trunk and pushes to the examples site.
>>>
>>> We really need to find a better solution for this!
>>>
>>> I say *disable* the job and have it only update at controlled times - not
automatically.
>>> Anything that needs to use it should have a flag/property to override the
urls needed to do local testing.
>>>
>>> But I know that does not scale well - anyone with a bright idea on how to fix
this better ?
>>>
>>> /max
>>>
http://about.me/maxandersen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> /max
>
http://about.me/maxandersen
>
>
>