Take the current version number, e.g. 1.0-SNAPSHOT and replace the -SNAPSHOT with -yourcompany-1
Thus.... as you work for vocaro.... if the plugin's SCM version that you've modified is 3.5.1-SNAPSHOT, you would release it as 3.5.1-vocaro-1 I would add that if you intend doing more that 10 such patch releases, start with 3.5.1-vocaro-01 Also, have a look at how maven specifies version numbers... some plugins don't understand this and you will have problems with them if they don't stick to the [major].[minor].[update]-[descriptor or build number] essentially, you are doing the "vocaro-01" release as opposed to the "alpha-01" release or the "beta-03" release 2008/12/23 Trevor Harmon <[email protected]> > There's a plugin I'd like to use, but it has some bugs that prevent me from > doing so. Fortunately, it's an open-source plugin, so I was able to fix the > bugs, but I'm not sure how to make the fixes available to others on my team. > Although I've submitted bug reports, there's no telling when (or if) the > bugs will be fixed upstream. > > I assume the best option is to change the version of my bug-fixed plugin, > deploy it to the team's repository, and have the other developers reference > this custom version number rather than the one on Central. Then, if the same > bugs are ever fixed upstream, the developers can simply reference that > version instead, and the one on the team repository will no longer be used. > > Is that the right course of action? If so, is there a convention on how to > choose a version number for this customized plugin? Thanks, > > Trevor > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
