> I'm not sure what the ASF thoughts would be on where to publish those,
> though, since I doubt the ASF release repo is the right place for that
Interesting. There is a recent discussion about this [in the general@
list](http://markmail.org/message/qtjqmzvgsg7w6j5s). But Take into account that
> Is that possible?
@grkvlt I think nightly builds sound like a pretty good idea, in general,
assuming we can get the release process sufficiently automated, of course. I'm
not sure what the ASF thoughts would be on where to publish those, though,
since I doubt the ASF release repo is the right
@nacx @demobox You're right, and we actually also do that. We would like a
predictable set of dependencies, so we end up making effectively a pre-release
version of jclouds that can be used as a fixed dependency, with a different
groupId. It works fine if we have a single release made for that j
Also, take into account that if at some point the forked version needs to be
published, say in Maven Central, then having a groupId different than the
jclouds one is a must, so I'd say using a custom groupId is the easiest way to
go for both jclouds and its forks.
---
Reply to this email direct
> I think the right approach for forks would be to change the groupId
Agreed. jclouds tries to stick to semver, and if private users want to use a
different version scheme, I'd say that it should be easy enough for them to
patch `JcloudsVersion` as needed? Not sure why that change would need to
Instead of hacking the version, I think the right approach for forks would be
to change the groupId. If at some point other software ends up depending on a
fork that has more features (or features not yet merged in jclouds) it is
*technically* not depending on jclouds, so I think the right appro
Closed #792.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/792#event-344193818
Forgot to adjust tests in `JcloudsVersionTest` to accept new strings. But,
since I'm not sure this is the right solution, having tried writing a new
regexp that parses semver metadata using `+` syntax, it introduces too much
complexity, so closing for now.
---
Reply to this email directly or vi
This allows building private forks with non-conflicting versions, since the
current regular expression matching sematic versions is very restrictive.
Versions such as `1.9.1-org-name.1` (for the first build of version 1.9.1 by
some organisation) should be allowed. All of the checks for alpha or
