11:37 a.m.
We have a number of additional maven projects that are pulled into
WildFly where in general their predominant purpose is for use within
WildFly.
For these kinds of projects I am wondering if it would make more sense
to drop using a version qualifier, this is compatible with our agreed
scheme: -
https://community.jboss.org/wiki/JBossProjectVersioning
The major and minor numbers are still available for us to be able to
branch off for maintenance, the micro then just becomes a tag counter.
At the moment we end up in situations where components need to move from
Beta to CR to Final at the appropriate time for a WildFly release even
though the modules are not actually being pushed as independent
projects, this creates additional work tagging and then processing the
component upgrades.
A couple of projects where this would make sense to me are JBoss
Negotiation and JBoss SASL, both of these are tied so closely to the
WildFly release that having their own qualifier does not add much.
An example project where retaining the qualifier is good would be JBoss
Remoting where it could easily be conceived that the chances are higher
it would be used as a stand alone project.
Regards,
Darran Lofthouse.
7 a.m.
What would this result into in practice?
Having snapshot dependencies in build as long as WildFly is in snapshot
version?
On Tue, May 20, 2014 at 6:37 PM, Darran Lofthouse <
darran.lofthouse(a)jboss.com> wrote:
We have a number of additional maven projects that are pulled into
WildFly where in general their predominant purpose is for use within
WildFly.
For these kinds of projects I am wondering if it would make more sense
to drop using a version qualifier, this is compatible with our agreed
scheme: -
https://community.jboss.org/wiki/JBossProjectVersioning
The major and minor numbers are still available for us to be able to
branch off for maintenance, the micro then just becomes a tag counter.
At the moment we end up in situations where components need to move from
Beta to CR to Final at the appropriate time for a WildFly release even
though the modules are not actually being pushed as independent
projects, this creates additional work tagging and then processing the
component upgrades.
A couple of projects where this would make sense to me are JBoss
Negotiation and JBoss SASL, both of these are tied so closely to the
WildFly release that having their own qualifier does not add much.
An example project where retaining the qualifier is good would be JBoss
Remoting where it could easily be conceived that the chances are higher
it would be used as a stand alone project.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
7:17 a.m.
On 21/05/14 13:00, Tomaž Cerar wrote:
What would this result into in practice?
Having snapshot dependencies in build as long as WildFly is in snapshot
version?
No components would still be tagged as normal, we just place less
emphasis on categorising them from through Alpha to Final.
As it stands today sometimes a component may not be tagged as Final
because it needs some time to be tested in place in WildFly (or EAP) -
if testing did not reveal any issues then the component needs to be
re-tagged just to set the qualifier to Final.
If during testing of WildFly a critical problem was found with the
sub-component a Blocker issue would be raised anyway to prevent the
release of WildFly until a fix is included so having the qualifier in
the modules version seems a little redundant.
I am thinking this may alos have an impact on splitting up WildFly, if
we are not careful we introduce the need for additional rounds of
tagging just to transition release qualifiers.
On Tue, May 20, 2014 at 6:37 PM, Darran Lofthouse
<darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
We have a number of additional maven projects that are pulled into
WildFly where in general their predominant purpose is for use within
WildFly.
For these kinds of projects I am wondering if it would make more sense
to drop using a version qualifier, this is compatible with our agreed
scheme: -
https://community.jboss.org/wiki/JBossProjectVersioning
The major and minor numbers are still available for us to be able to
branch off for maintenance, the micro then just becomes a tag counter.
At the moment we end up in situations where components need to move from
Beta to CR to Final at the appropriate time for a WildFly release even
though the modules are not actually being pushed as independent
projects, this creates additional work tagging and then processing the
component upgrades.
A couple of projects where this would make sense to me are JBoss
Negotiation and JBoss SASL, both of these are tied so closely to the
WildFly release that having their own qualifier does not add much.
An example project where retaining the qualifier is good would be JBoss
Remoting where it could easily be conceived that the chances are higher
it would be used as a stand alone project.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3891
days inactive
3892
days old
2 comments
2 participants
participants (2)
-
Darran Lofthouse -
Tomaž Cerar