[jbosstools-issues] [JBoss JIRA] (JBDS-3191) Improve the way we switch between development and GA

Nick Boldt (JIRA) issues at jboss.org
Mon Oct 20 08:45:37 EDT 2014


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

Nick Boldt edited comment on JBDS-3191 at 10/20/14 8:44 AM:
------------------------------------------------------------

Please note that the first line item in the release guide for JBDS 8 milestones is (re: JBDS-3190):

{quote}
TODO: when releasing GA make sure to :%s/development/stable/g and :%s/8.0-staging/8.0/g in product/features/com.jboss.jbds.product.feature/p2.inf 
{quote}

Having the stable site in there from day 1 (I assume you mean the day Beta1 is pushed to https://www.jboss.org/products/devstudio ) will mean that everyone using the Betas won't be able to see updates, and won't be able to automatically move up to CR or GA.

Alternatively, if you add BOTH the release site and the milestone site, you still need to configure p2.inf to remove the development site when updating to GA from an earlier milestone. And worse, Max will complain that there are too many sites listed in the Available Software Sites view. :D

I think it's better to define maven enforcer rules which run at build-time to cause the build to fail if parent pom version is Final and the above files still contain development milestone (not release/stable) URLs. 

But yes, factorizing the update site URL (https://devstudio.redhat.com/updates/8.0-development/ or https://devstudio.redhat.com/updates/8.0/ ) into a single variable is a good idea.



was (Author: nickboldt):
Please note that the first line item in the release guide for JBDS 8 milestones is (re: JBDS-3190):

{quote}
TODO: when releasing GA make sure to :%s/development/stable/g and :%s/8.0-staging/8.0/g in product/features/com.jboss.jbds.product.feature/p2.inf 
{quote}

Having the stable site in there from day 1 (I assume you mean the day Beta1 is pushed to https://www.jboss.org/products/devstudio ) will mean that everyone using the Betas won't be able to see updates, and won't be able to automatically move up to CR or GA.

I think it's better to define maven enforcer rules which run at build-time to cause the build to fail if parent pom version is Final and the above files still contain development milestone (not release/stable) URLs. 

But yes, factorizing the update site URL (https://devstudio.redhat.com/updates/8.0-development/ or https://devstudio.redhat.com/updates/8.0/ ) into a single variable is a good idea.


> Improve the way we switch between development and GA
> ----------------------------------------------------
>
>                 Key: JBDS-3191
>                 URL: https://issues.jboss.org/browse/JBDS-3191
>             Project: Developer Studio (JBoss Developer Studio)
>          Issue Type: Enhancement
>          Components: build
>            Reporter: Mickael Istria
>
> JBDS-3190 has shown that there are too many changes to perform when willing to create a GA candidate, and it's almost certain that we'll forever forget to change one or some of them when switching between GA and development stream.
> We need to improve that.
> Changes are necessary in:
> * features/com.jboss.devstudio.core/feature/p2.inf
> * site/associate.properties
> * results/pom.xml
> As an alternative, I suggest that the final site be ALWAYS added to the referenced site, even if it's empty. This has no cost for build nor user, and this would simplify a few things here and there.
> Also, instead of a p2.inf, we could think a a "startup" extension that would add reference to development site in case qualifier for the feature doesn't contain GA.
> The property to the "current site" (GA or development) could be factorized in JBDS parent pom. so that both results/pom.xml and site/pom.xml could use it (instead of associateSites.properties).
> CC [~nickboldt] [~maxandersen]



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)


More information about the jbosstools-issues mailing list