That's completely reasonable -- we don't have more than one version in
production at a given time, however.
On Tue, Feb 1, 2011 at 9:29 PM, Ron Wheeler
<rwhee...@artifact-software.com>wrote:
> On 01/02/2011 11:03 AM, Mate Varga wrote:
>
>> 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).
>>
> We are very small as well but we really do need the branching and tagging
> to enable us to support and fix bugs in multiple versions that are in
> production plus test and development.
>
> Ron
>
> 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
>> <rwhee...@artifact-software.com>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
>>>> <rwhee...@artifact-software.com>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<
>>>>>> stephen.alan.conno...@gmail.com> 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"<mate.va...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
