We started by changing the versions of everything but as we got to 70
modules for the application we stopped.
We stepped back and started to look at our code in the same way that we
looked at third party (Apache, Spring, etc.) libraries that we used.
We were perfectly able to use the same version of Spring through several
generations of the application so why could we not keep using the same
version of
com.artifact-software.util:message if the messaging utility was unchanged.
At the start of a new version of the application we update a spreadsheet
of all of the modules by identifying each of the modules that will change.
We are usually pretty accurate in our initial scoping since the modules
are organized by function.
We have also moved a lot of the utility functions out of the business
code so they are more stable and do not change in the usual course of
maintenance.
This review usually takes less than an hour and after it is done
everyone is on the same page in terms of scope.
The spreadsheet also give a bit of a historical view of each of the new
versions.
Suppose you have to go back and understand why module x changed from
version 1.10.3 to 1.10.4 last year.
You can see at a glance what other modules also got new versions at the
same time.
This can sometimes be more helpful than a list of bugs fixed.
In our case, we will version the revised module with the version number
of the application that caused its generation so it is "legal" for us to
have a 1.10.3 and a 1.10.6 with no 1.10.4 or 1.10.5 if the module was
unchanged from when the 1.10.3 was created until the 1.10.6 version
required a modification.
Ron
On 08/04/2012 10:43 AM, Rajwinder Makkar wrote:
True .. personally i am also not in favor of bumping version of all
artifacts when only one artifacts has changed in the project. This also
leads to addition of extra space in artifactory or any repo manager as the
same artifact will be stored with just diff version number without any
need. Consumers of the artifact who are watching it also get confused as
for them a new version is available but functionality is same ;-)
Thanks for the response.
-Raj
On Sun, Apr 8, 2012 at 2:12 AM, Anders Hammar<and...@hammar.net> wrote:
Your described scenario is the common scenario for Maven. You should
never change (or delete) a release. Your repo manager should always be
configured to deny that.
You're describing the two possible solutions. Either bump the version
on all artifacts produced, or just deploy the artifact that has
changed (with a new version number). Which way to go depends on the
version management choice of your project. Most open source projects
simply deploy a new version of all artifacts, as they go together as a
family. But from a CM perspective that can sometimes be confusing as,
for example, it means that the API version is bumped while there are
no changes to it (in case of a bug fix in the core implementation).
But having a separate version lifecycle for different parts of your
application will increase the release management work.
Personally I'm in favor of having separate release lifecycle for at
least the API if it's clearly separate (like for a web service's
wsdl). But having separate releases for different parts of an
applications internal stuff most often is just too cumbersome.
/Anders
On Sun, Apr 8, 2012 at 07:27, Rajwinder Makkar<rmakkaroff...@gmail.com>
wrote:
Here is a dev scenario :
We are using maven 3 + artifactory + microst TFS server
We dont want to over write an existing version of an artifact in our
company repo , so the the consumers of artifacts should not be surprised
all the sudden when producers update artifact.
Now this can simply be done by removing delete permissions in artifactory
but then that causes another problem. In multi module maven project if
one
module changes then either dev need to modify version on all artifacts (
which doesnt make sense ) or then need to modify individual pom and
publish
only the artifact that is changes * which again is not manageable )
So need some advice on how this can be handled ?
I have couple of thoughts :
- Before running mvn command , write some thing custom to go through all
pom's and query artifactory is version of artifact exist. if yes then
dont
compile. Basically compile only artifacts who version doesnt exist in
artifactory using "mvn -pl "
- Try Jenkins , I know jenkins is aware of modules in project , but not
sure if it intelligent enough to compile only those which are changed ?
Please advice
-Raj
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
