aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Semantic versioning tool and updating packageinfos
Date Thu, 29 Nov 2012 21:22:33 GMT
Hi David,

You can turn off the automatic packageinfos with a plugin flag.  But I'm not sure what your
problem with them is.  They aren't committed to your version control system, they just show
you what the correct version is for your current code.  If you changed something unintentionally
you can revert the packaginfo change and fix your code.  It lets e.g. git status show you
what packages need attention :-)

I haven't looked in a long time but I'm also 99% sure that if you increment a package version
for some reason not supported by the code, it won't argue with you.

I do think that having an option to fail the build would be a good idea.... although you may
find it easier to do a full build and run git status on a multimodule project rather than
having a failure at the first problem.  I guess a "fail at the end of the build" might be
nice, but I'm not sure how to do that.

Does this change your thinking at all?

thanks
david jencks


On Nov 29, 2012, at 8:22 AM, David Bosschaert wrote:

> Just reading my mail again and notice that I wasn't too clear in cases
> where version information is missing. In any case I would not be so much in
> favour of autocorrection and think that failing the build with suggested
> fixes would be better.
> 
> 
> On 29 November 2012 16:03, David Bosschaert <david.bosschaert@gmail.com>wrote:
> 
>> I think it would be better to fail the build and suggest the proper
>> version to the user in all cases where version information is incorrect. It
>> could be the case that the user unintentionally made a change that would
>> bump the version and may want to review those changes in the code instead
>> of bumping the version.
>> 
>> BTW you're talking about bundle versions, but I suppose you mean package
>> versions?
>> 
>> David
>> 
>> 
>> On 29 November 2012 15:11, Emily Jiang <emijiang6@googlemail.com> wrote:
>> 
>>> With David (Jencks)'s help, I managed to integrated the versioning maven
>>> plugin into a few projects. At the moment, the plugin will display the
>>> versioning report in the build and then overwrite the wrong version in the
>>> package-info.java. If the bundle version is incorrect, it just lists what
>>> the version should be instead of overwrite it directly. May I suggest we
>>> only fail the build if the bundle version is incorrect and leave the other
>>> errors being autocorrected by the plugin? Thoughts?
>>> 
>>> By the way, you will need to ugrade your maven version to 3.x to be able
>>> to
>>> run the plugin.
>>> 
>>> Thanks
>>> Emily
>>> 
>>> On Mon, Nov 26, 2012 at 10:08 PM, Emily Jiang <emijiang6@googlemail.com
>>>> wrote:
>>> 
>>>> Further to David J's comments, in order to fail a build, I think we can
>>>> parse the report xml doc. If there is an entry, we can fail the build,
>>>> which is trivial thing to do. David, if you can supply the snippet of
>>> your
>>>> maven plugin, I can help to integrate this tool in our trunk. Sorry. It
>>> has
>>>> been on my todo list, but I did not get to it. well. maybe now is the
>>>> time(*sigh*)
>>>> 
>>>> Thanks
>>>> Emily
>>>> 
>>>> 
>>>> On Mon, Nov 26, 2012 at 6:20 PM, David Jencks <david_jencks@yahoo.com
>>>> wrote:
>>>> 
>>>>> I turned Emily's code into a maven plugin, but I'm not sure I succeeded
>>>>> in documenting it.  Mostly it puts correct packaginfo files into the
>>> source
>>>>> tree and generates a sort-of report of problems.  I don't think it
>>> fails
>>>>> the build.  You have to specify what the base you are comparing
>>> against is,
>>>>> IIRC in the plugin configuration.   I'm off today but will try to
>>> figure it
>>>>> out soon unless someone beats me to it.
>>>>> 
>>>>> 
>>>>> thanks
>>>>> david jencks
>>>>> 
>>>>> On Nov 26, 2012, at 7:46 AM, Holly Cummins wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> As promised, I've started work on our next batch of releases. This
>>> one
>>>>>> should be way easier than the last batch I did, because it's way
>>>>> smaller.
>>>>>> However, one thing which is harder is that last time I knew what
the
>>>>>> package and bundle versions were (1.0.0 across the board). This time
>>> I
>>>>> have
>>>>>> to think about it and choose sensible versions.
>>>>>> 
>>>>>> Our version policy page (
>>>>>> http://aries.apache.org/development/versionpolicy.html) confidently
>>>>> says
>>>>>> that setting bundle versions for a release should be easy because
the
>>>>>> packages will already have the correct version. Sadly, the sample
of
>>> one
>>>>>> package I've checked so far has changes, but no bump to the package
>>>>> number.
>>>>>> This means the release manager will need to verify/set both package
>>> and
>>>>>> bundle version numbers. In the ideal case the packageinfo will be
>>>>> correct,
>>>>>> but if we can't *guarantee* it's correct, it needs to be checked
by
>>> the
>>>>>> release manager.
>>>>>> 
>>>>>> Sifting through code changes by hand sounds both boring and
>>> unscalable
>>>>> to
>>>>>> me, so I'd like to revive the conversation about Emily's semantic
>>>>>> versioning tool. My questions are
>>>>>> 
>>>>>> (a) Can the tool help me do this batch of checking, and if so, can
>>>>> someone
>>>>>> send me idiot's instructions? I'm sure it's documented, but my
>>> initial
>>>>>> google wasn't successful.
>>>>>> (b) Longer term, wouldn't it be great to get the tool integrated
into
>>>>> the
>>>>>> release plugin? I know we've discussed this before, so I'm mostly
>>>>> chipping
>>>>>> in again with a "yes please, +1" :)
>>>>>> 
>>>>>> (I think last time we discussed this someone suggested that bnd could
>>>>>> assign version numbers, but my searching suggests that's only in
an
>>>>> as-yet
>>>>>> unreleased version.)
>>>>>> 
>>>>>> Holly
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Thanks
>>>> Emily
>>>> =================
>>>> Emily Jiang
>>>> ejiang@apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Thanks
>>> Emily
>>> =================
>>> Emily Jiang
>>> ejiang@apache.org
>>> 
>> 
>> 


Mime
View raw message