Perforce, and we're strict about comments as well, but we don't really do branching and tagging (the dev team size is just too small). It does not need to be very easy to tie source to snapshots.
Besides that, is what I've written about snapshots correct? On Tue, Feb 1, 2011 at 3:52 PM, Ron Wheeler <[email protected]>wrote: > What version control system are you using? > > We are using Subversion and are pretty strict about: > a) Branching and tagging > b) Comments. > > The fundamental question is "How easy does it have to be to tie a source > version to a snapshot?" > We very seldom need to go back and do a forensic reconstruction of the > crime. > When we do, we have comments and commit dates in the SCM that can be > matched against other evidence (paper notes, Snapshot dates, e-mails, etc.) > to determine where the source and the other event (test, presentation, > e-mail, bug report) coincide in time. > > SNAPSHOTS and Subversion commits are both dated so it is always possible to > match them. > It has been required less than 3 times in the past 4 years that we have > been developing with Subversion and Maven, so the extra time to read a > history or go through a set of Maven Artifacts (we have Nexus) is not really > a determining factor in our selection of a methodology and development > protocol. > > > Ron > > > On 01/02/2011 10:14 AM, Mate Varga wrote: > >> That sounds right. >> As far as I know, Maven assumes that releases are immutable, but snapshots >> are not. So I could just use {some version number}-SNAPSHOT for all of our >> projects and they would depend on each others' snapshot versions. >> As far as I remember, the reason why I've chosen version numbers instead >> of >> SNAPSHOTs is that given a 'snapshot' (not in the Maven sense) of a project >> and it's runtime dependencies, it is possible to go and find the sources >> he >> artifacts were built from. >> So in our current setup, a self-containing 'release' of project a contains >> A-12.jar >> B-19.jar >> C-123.jar >> D-111.jar >> >> The version numbers are CI build numbers. Using snapshots (and without >> manual versioning), this would look like A-1-SNAPSHOT, B-1-SNAPSHOT, etc. >> However, this should not be a problem as there are hundred other ways of >> tying an artifact to a build / source revision... >> >> So you recommend just using a fixed version and SNAPSHOTs instead of >> 'RELEASE's? >> >> Sorry for being confusing, this is my first encounter with Maven (and even >> with these hacks it's much more convenient than Ant, at least for our >> purposes). >> >> Thanks, >> Mate >> >> On Tue, Feb 1, 2011 at 2:43 PM, Ron Wheeler >> <[email protected]>wrote: >> >> It does seem that you are describing the way SNAPSHOTS work. >>> >>> Can you identify any particular problem in your environment that prevents >>> you from working according to the Best Practices that thousands of >>> organizations are following? >>> I can not see from anything that you have described so far that is >>> abnormal. >>> We have 70 projects that make up a large LMS and it depends on 60+ third >>> party libraries and most of the war files include dependencies on our >>> utilities and web services. >>> >>> We do not use CI but dozens of regulars here do and can help make that >>> work >>> correctly. >>> >>> Can you give a short description of the issues that made you abandon >>> SNAPSHOTS? >>> >>> >>> Ron >>> >>> >>> On 01/02/2011 9:22 AM, Mate Varga wrote: >>> >>> What assumptions do I break except the immutability of an artifact with >>>> a >>>> specific version? (Which is only broken locally, and mvn should not >>>> really >>>> know about it, and it should not affect anything as mvn does not copy >>>> local >>>> artifacts anywhere.) >>>> >>>> Well, then the easiest thing is to explain what I'd like to do -- and >>>> maybe >>>> there's some other way to achieve it. >>>> >>>> (let's assume we have 3 projects, A, B, C,D; A depends on B, B depends >>>> on >>>> C >>>> and A depends on D >>>> - we don't have major / minor versions at all -- we do not want and we >>>> do >>>> not need a separate release procedure. Every successful CI build is >>>> considered to be a new version. Obviously, successful CI builds should >>>> be >>>> handled as snapshots, but if project B has been successfully built in >>>> the >>>> CI, then each following build of A should be using that version. >>>> Therefore >>>> the version numbers should be incremented automatically (CI build number >>>> could be used for that) >>>> - developers should be able to modify and build project B locally, and >>>> then >>>> modify and build A (and A should use B which was built locally) >>>> >>>> Currently, what I do is >>>> - have two profiles, a 'local' and a 'CI', which are activated >>>> automatically >>>> depending on the environment >>>> - after successful CI builds, artifacts are deployed to the repo manager >>>> (this works perfectly) >>>> - locally built artifacts have version no. 99999999 >>>> - if an internal project references another internal project, then it >>>> refers >>>> to its 'LATEST' version >>>> >>>> Are there other ways to achieve similar results? Please do not criticize >>>> the >>>> way we do releases, as this is 'given', and it's the result of the >>>> environment we work in. We cannot have major/minor releases, nor can we >>>> manually version each release. I'd be very happy if there were a proper >>>> way >>>> to do what we're doing in a bit hacky way now. >>>> >>>> Thanks, >>>> Mate >>>> >>>> On Tue, Feb 1, 2011 at 1:22 PM, Stephen Connolly< >>>> [email protected]> wrote: >>>> >>>> ugh this is just so wrong I don't know where to start. >>>> >>>>> please consider using SNAPSHOTS as they are the correct way >>>>> >>>>> LATEST and RELEASE do not mean what you think they mean, and they have >>>>> been >>>>> deprecated. their use is no longer supported. >>>>> >>>>> maven makes assumptions about non-SNAPSHOT versions which you are >>>>> breaking >>>>> behind its back. >>>>> >>>>> there be dragons here >>>>> >>>>> - Stephen >>>>> >>>>> --- >>>>> Sent from my Android phone, so random spelling mistakes, random >>>>> nonsense >>>>> words and other nonsense are a direct result of using swype to type on >>>>> the >>>>> screen >>>>> On 1 Feb 2011 11:13, "Mate Varga"<[email protected]> wrote: >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>> 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] > >
