Oh, yes, I'm aware that the release version is captured in the tag and that
is not lost from the SCM, but it leaves the Jenkins workspace in an
inconsistent state.
I thought of creating a job tied to the svn tag, but it's not correct
because we often have multiple "releases" when deploying to QA. So that
means you would have to update the SCM path everytime you perform the
release.
On top of that, my point is that it breaks pipeline design. Downstream jobs
need to rely on the values that correspond to that release build, not the
upcoming one.
This problem could be solved if the plugin used a temp folder for tag
creation instead of stepping over the released files.
On Thu, Mar 29, 2012 at 5:52 AM, Noam Y. Tenne <[email protected]> wrote:
> Thanks for the clarification.
>
> Although the POMS return to a snapshot version after a release build, (in
> SVN at least) a tag is created with the released version before committing
> the new development version; so the released version is not really lost
> from the SCM.
>
> How about maintaining a separate release branch and have the downstream
> job depend on it instead of the dev?
>
>
> On Thu, Mar 29, 2012 at 5:02 AM, Nicky Ramone <[email protected]> wrote:
>
>> Yes, sure. I'll try to rephrase:
>>
>> Consider releasing foo 1.0-SNAPSHOT
>> I noticed that, after the release, the POMs in the job workspace are
>> incremented up to the next development version.
>> So, before the release, the POM version is 1.0-SNAPSHOT. After the
>> release, it is 1.1-SNAPSHOT, but I think that it should be 1.0
>>
>> While the 1.1-SNAPSHOT looks harmless, it doesn't seem correct. If you
>> define a build pipeline with a downstream job that depends on using that
>> POM, it needs the 1.0, not 1.1-SNAPSHOT. The POM containing 1.1-SNAPSHOT
>> should come up in the next build, not in that current build.
>>
>> This is an example of how the job workspace ends up after each build:
>> <Type of build triggered> -> <POM version that you can find in the job
>> workspace>
>> Regular build -> 1.0-SNAPSHOT
>> Regular build -> 1.0-SNAPSHOT
>> Release staging -> 1.1-SNAPSHOT
>>
>> I understand that the 1.1-SNAPSHOT is there as a result of the "next
>> development version commit" performed at the release, but it seems wrong.
>> That last build should represent 1.0, not 1.1-SNAPSHOT. As I said above, it
>> affects downstream jobs that need to access/copy that POM file.
>>
>> Let me know if it's more clear now.
>> Thanks.
>>
>> On Wed, Mar 28, 2012 at 9:04 AM, Noam Y. Tenne <[email protected]> wrote:
>>
>>> Hi Nicky,
>>>
>>> While I understand the problem that you've presented, I don't think I
>>> understand your question; can you please elaborate?
>>>
>>> Thanks,
>>> Noam
>>>
>>> On Tue, Mar 27, 2012 at 6:00 PM, Nicky Ramone <[email protected]> wrote:
>>>
>>>> Hello.
>>>>
>>>> When you perform an "Artifactory Release Staging", on a 1.0-SNAPSHOT
>>>> artifact, it is released as 1.0 and then the workspace pom is upgraded to
>>>> the next snapshot version, like 1.1-SNAPSHOT.
>>>> The problem is that if you are in a build pipeline, you have other jobs
>>>> that may be interested in working with the released files (i.e., they want
>>>> to deal with 1.0 and not 1.1-SNAPSHOT). For the next POM versions Jenkins
>>>> would pick up the upgraded pom files anyway.
>>>>
>>>> Is there a reason why the POMs are upgraded in the workspace other than
>>>> to check in the modified POMs?
>>>>
>>>> Thanks.
>>>> Cheers.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF email is sponsosred by:
>>>> Try Windows Azure free for 90 days Click Here
>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>> _______________________________________________
>>>> Artifactory-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> Artifactory-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Artifactory-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Artifactory-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
