[jbosstools-issues] [JBoss JIRA] (JBIDE-15252) Agree on a release URL for locus

Nick Boldt (JIRA) jira-events at lists.jboss.org
Thu Jul 18 14:25:26 EDT 2013


    [ https://issues.jboss.org/browse/JBIDE-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790819#comment-12790819 ] 

Nick Boldt edited comment on JBIDE-15252 at 7/18/13 2:24 PM:
-------------------------------------------------------------

I would think we want a "latest best" URL too, which would initially point to 1.0.0, then later 1.0.1, etc.

Convention dictates that everything under /updates/ is then qualified by a TYPE or release:

http://download.jboss.org/jbosstools/updates/stable/
http://download.jboss.org/jbosstools/updates/development/
http://download.jboss.org/jbosstools/updates/integration/
http://download.jboss.org/jbosstools/updates/nightly/

And, to avoid having lots of locus-* folders in the root of /updates/, I'd prefer to see locus/<version>/ than locus-<version>/.

Thus, I would suggest this:

http://download.jboss.org/jbosstools/updates/stable/locus/ --> points to latest stable release
   -> http://download.jboss.org/jbosstools/updates/stable/kepler/core/locus/

This pattern is the same for JBoss Tools:

http://download.jboss.org/jbosstools/updates/stable/ --> points to latest stable release
   -> http://download.jboss.org/jbosstools/updates/stable/juno/ (currently 4.0.1)

In fact, we already (sort of) have this, but only for /integration/ since we haven't had a /development/ or /stable/ release yet:

http://download.jboss.org/jbosstools/updates/integration/locus/ (manually updated to point at latest release, which is currently Juno)
   -> http://download.jboss.org/jbosstools/updates/integration/kepler/core/locus/

I think we need to decide, like with Orbit (and its R-build releases which are not always backward compatible w/ previous releases), if 1.0.0 is a "Juno+" release, or since it's used for projects which are based on Kepler, whether it should be considered a "Kepler+" release. And then going forward, if we decide a baseline eclipse target based on the stuff that uses it, or what's in Locus & its TP. 

Personally, I think it makes sense for Locus 1.0.0 to be under /stable/kepler/core/locus/1.0.0.Final/, because:

* it's stable
* it's used by Kepler-based projects
* core is there because it lets me use my existing promote.sh script w/o having to change it ( #laziness #reuse )
* it's locus (/locus/ is a composite of all the contained releases therein)

Then, if we do a Locus release that depends on Luna, it would be /stable/luna/core/locus/1.1.0.Final/, but all subsequent releases depending on Kepler would be 1.0.x.

Make sense?
                
      was (Author: nickboldt):
    I would think we want a "latest best" URL too, which would initially point to 1.0.0, then later 1.0.1, etc.

Convention dictates that everything under /updates/ is then qualified by a TYPE or release:

http://download.jboss.org/jbosstools/updates/stable/
http://download.jboss.org/jbosstools/updates/development/
http://download.jboss.org/jbosstools/updates/integration/
http://download.jboss.org/jbosstools/updates/nightly/

And, to avoid having lots of locus-* folders in the root of /updates/, I'd prefer to see locus/<version>/ than locus-<version>/.

Thus, I would suggest this:

http://download.jboss.org/jbosstools/updates/stable/locus/ --> points to latest stable release, like we do for JBoss Tools, in http://download.jboss.org/jbosstools/updates/stable/

In fact, we already (sort of) have this, but only for /integration/ since we haven't had a /development/ or /stable/ release yet:

http://download.jboss.org/jbosstools/updates/integration/locus/ (manually updated to point at latest release, which is currently Juno)
   -> http://download.jboss.org/jbosstools/updates/integration/juno/core/locus/
   -> http://download.jboss.org/jbosstools/updates/integration/kepler/core/locus/

I think we need to decide, like with Orbit (and its R-build releases which are not always backward compatible w/ previous releases), if 1.0.0 is a "Juno+" release, or since it's used for projects which are based on Kepler, whether it should be considered a "Kepler+" release. And then going forward, if we decide a baseline eclipse target based on the stuff that uses it, or what's in Locus & its TP. 

Personally, I think it makes sense for Locus 1.0.0 to be under /stable/kepler/core/locus/1.0.0.Final/, because:

* it's stable
* it's used by Kepler-based projects
* core is there because it lets me use my existing promote.sh script w/o having to change it ( #laziness #reuse )
* it's locus (/locus/ is a composite of all the contained releases therein)

Then, if we do a Locus release that depends on Luna, it would be /stable/luna/core/locus/1.1.0.Final/, but all subsequent releases depending on Kepler would be 1.0.x.

Make sense?
                  
> Agree on a release URL for locus
> --------------------------------
>
>                 Key: JBIDE-15252
>                 URL: https://issues.jboss.org/browse/JBIDE-15252
>             Project: Tools (JBoss Tools)
>          Issue Type: Task
>          Components: locus
>            Reporter: Mickael Istria
>             Fix For: 1.0.0-LOCUS
>
>
> In order to make it release URL easy to remember and predictable, we need to agree on a pattern for Locus releases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbosstools-issues mailing list