If I'm not changing the source, then I like to use the scm version of the source I pulled from the external source. That way I can always go back and easily update it. Something like 3.5.1-vocaro-[svnrev]. This saves me from having to pull the whole source into my scm. (provided I trust the remote won't disappear) In your case you will probably need to check it in anyway since you're making changes so the scm rev is probably not usefull.
-----Original Message----- From: Stephen Connolly [mailto:[email protected]] Sent: Tuesday, December 23, 2008 11:26 AM To: Maven Users List Subject: Re: Deploying a customized plugin 2008/12/23 Stephen Connolly <[email protected]> > 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] BTW, the importance of this is when there is a real release. in fact as I think about this more... i'd nearly recommend using 3.5.1-aavocaro-01 that way if they release 3.5.1-alpha-01 after your release then Maven's version sorting rules will be ok... if you are patching an alpha release e.g. 3.5.1-alpha-2-SNAPSHOT... you can do 3.5.1-alpha-2-vocaro-01 > > > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
