aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Semantic versioning tool and updating packageinfos
Date Fri, 30 Nov 2012 08:00:26 GMT
Hi Emily and David,

I think requiring that the developer actually change the package-info files
makes him/her more aware of what (s)he's doing and will give the developer
a better understanding of semantic versioning in the end. Otherwise, even
if you have a separate step of committing, you could get into a situation
where the developer goes 'yeah whatever' and simply commits the tool's
changes without properly looking, which in the end could have the effect of
the developer not understanding the package-info files and the versioning
strategy at all any more.

In the case of the tool making these modifications, there is also the issue
of whether the tool generates package-info or package-info.java files,
since both are understood by bnd. Well, I guess you could make that
configurable with a switch.

In any case, I think that source code is for developers to modify, not for
tools (I know this is not universally agreed, my opinion anyway). As a
parallel, look at a compiler, e.g. javac. Let's say I forgot to cast a
class in my code. It might be obvious to fix this, but still the compiler
doesn't do it for me. It will just give tell me that I didn't do it right
and will me give a suggestion. Then I need to use that information to go
and fix it properly, which might actually turn out to be different than the
compiler told me.

Cheers,

David


On 29 November 2012 21:22, Emily Jiang <emijiang6@googlemail.com> wrote:

> Hi David,
>
> Thanks for your reply. I quite like the feature of overwriting the
> package-info version:o. When you run the maven build, there will be report
> telling why you need to change to the recommended version. It is still up
> to you to review the changes and then commit them. If it fails build, you
> need to manually change the version and then commit. I am trying to
> understand why you prefer to do it yourself instead of relying on the tool
> and you just review/commit it.
>
> Thanks
> Emily
>
> On Thu, Nov 29, 2012 at 4:22 PM, David Bosschaert <
> david.bosschaert@gmail.com> 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
> > >>
> > >
> > >
> >
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message