Noooo you mis-interpret.

A standalone REST-bot that has the permissions and does some validation and
then makes the call on your behalf.

That way you don't need to redefine permissions... and you can restrict the
scope of actions to finer than JIRA allows, e.g. ensuring that version
numbers respect specific patterns, prevent bulk creation, etc.

but hey I am fine with redefining them if that's what we want to do...
never had an abuse issue with mojo@codehaus and letting developers create
versions. I think the only reason the permissions are the way they are ATM
is because we only use *current* as a version


On 13 January 2014 10:12, Mirko Friedenhagen <[email protected]>wrote:

> Stephen, AFAIK currently only project admins  are allowed to create
> versions, so you have to redefine permissions as well that all people in
> role user/member may create versions.
>
> Regards
> Mirko
> --
> Sent from my mobile
> On Jan 13, 2014 12:32 AM, "Stephen Connolly" <
> [email protected]> wrote:
>
>> What you mean is a REST service that uses your deployment credentials to
>> create/mark released versions... And then add a goal(s) to hpi maven plugin
>> to call that REST service...
>>
>> I don't see why not
>>
>> On Sunday, 12 January 2014, Slide wrote:
>>
>>> Could it also be made part of the release process? That way during
>>> release it could be added automatically.
>>> On Jan 12, 2014 2:19 PM, "Ulli Hafner" <[email protected]> wrote:
>>>
>>> That would be a good idea!
>>>
>>> I think we need both variants:
>>> a) automatically generated versions for reporters to set the affected
>>> version (which should be a mandatory field then), these versions need to
>>> have a status „Released"
>>> b) IRC bot commands to create a new version for a developer to plan the
>>> next release (status is ‚Unreleased‘), and another command to release that
>>> version
>>>
>>> Am 12.01.2014 um 20:02 schrieb Stephen Connolly <
>>> [email protected]>:
>>>
>>> Far far simpler... we just index the poms in the repo and create
>>> versions every time the index runs...
>>>
>>> That way there is a version for every release, since people want to
>>> report issues against released versions... if you are cutting a release
>>> with new known issues you can wait the 24hr anyway... or use the IRC bot
>>>
>>>
>>> On 12 January 2014 18:52, Dominik Bartholdi <[email protected]> wrote:
>>>
>>> Maybe a simple web ui would do too, as I think not all devs have “voice”
>>> on IRC (and maybe not all should have)
>>> on the other hand, one is not forced to use these versions and maybe a
>>> user with “voice” can create the version if required.
>>> /Domi
>>>
>>> On 12.01.2014, at 19:41, Slide <[email protected]> wrote:
>>>
>>> That would be great, though I am not sure all plugin developers hang out
>>> on IRC, it would definitely be a start though. I'll take a look at it.
>>>
>>>
>>> On Sun, Jan 12, 2014 at 11:25 AM, Dominik Bartholdi <[email protected]>wrote:
>>>
>>> Maybe we can add another command to the IRC bot?
>>> /Domi
>>>
>>> On 12.01.2014, at 18:36, Slide <[email protected]> wrote:
>>>
>>> Would these be controller by the plugin developers? I can see a problem
>>> if admins have to add the versions every time. Some plugins have a pretty
>>> rapid development cycle compared to others.
>>>
>>> Thanks,
>>>
>>> slide
>>>
>>>
>>> On Sun, Jan 12, 2014 at 3:11 AM, Dominik Bartholdi <[email protected]>wrote:
>>>
>>> A while a go we had a discussion about reorganizing JIRA as a whole, I
>>> think someone was going to to a "prove of concept” with things like:
>>> - separate projects for each plugin
>>> - a naming convention for versions of different components.
>>>
>>> I don’t know what happen to that POC, but I think the first one is quite
>>> hard to change a time present, as we have already such a huge history of
>>> issues.
>>> But I guess the second would be quite easy to do, e.g. versions could be
>>> prefixed with the component id
>>> - scriptler-1.1
>>> - parameterized-trigger-2.16
>>>
>>> /Domi
>>>
>>> On 11.01.2014, at 23:48, Slide <[email protected]> wrote:
>>>
>>> The "current" version tag is almost completely useless if you are
>>> looking back at bugs from a while ago. Users could be on what they _think_
>>> is current, but it could be old. Can we please remove this as a possible
>>> version so that people can't use i
>>>
>>>
>>
>> --
>> Sent from my phone
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to