On Monday 20 September 2010 21:50:30 Perez Ronen wrote: > 1) Do you agree with me that the SNAPSHOT way is better? No you can achieve the same and more with releases and version ranges. > > 2) Can you give your reasons of why this is better? When integrating artifacts against a snapshot its meaningless just like giving a tester snapshots is meaningless the result is not deterministic.
By specifying a range you are defining a constrained but flexible relationship which can be checked. For example this works fine War 1 depends on B 1.1-SNAPSHOT and C 1.1-SNAPSHOT B depends on A 1.1-SNAPSHOT C depends on A 1.1-SNAPSHOT But what if you have many wars War 2 depends on B 2.1-SNAPSHOT and C 3.1-SNAPSHOT B 2.1-SNAPSHOT depends on A 2.1-SNAPSHOT C 3.1-SNAPSHOT depends on A 3.1-SNAPSHOT might give you 3.1-SNAPSHOT or 2.1-SNAPSHOT when really it should be an error. I use War 2 depends on B [2,3) and C [3,4) with B 2.1-SNAPSHOT depends on A [2,3) and C 3.1-SNAPSHOT depends on A [3,4) gives you a conflict someone tried to merge 2 incompatible versions of A i.e. line 2 and line 3. I'm not sure why more people don't suffer these headaches, maybe they don't have large enough projects or enough deliverables. Most of the projects I work on delivery several wars with many shared artifacts. If thats not enough consider, one of the biggest hassles I used to have on projects was people checking in broken code, that would stop other developers from working. With snapshot dependencies you have exactly the same problem but worse as you don't need to update or you do. Finding a stable combination of snapshots and updated working copies is hard and prone to error. If you require that a developer release artifacts before you see their changes 1) if it breaks you just change your deps to use the previous version till they fix it 2) people are not afraid to commit code as someone has to release an artifact before its shared 3) continuous integration tools can check the head to head and head to latest releases for each artifact > > Thanks, > Ronen. > > > ________________________________ > "This e-mail message may contain confidential, commercial or privileged > information that constitutes proprietary information of Comverse Technology > or its subsidiaries. If you are not the intended recipient of this message, > you are hereby notified that any review, use or distribution of this > information is absolutely prohibited and we request that you delete all > copies and contact us by e-mailing to: [email protected]. Thank You." > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
