You should *always* have a version. If it's a public app/library then go with semantic versioning.
If it's in-house, then you'll be doing continuous releases, or even continuous deployment (if not, why not?). Every CI system known to man has the concept of a build number, use *that* as your version, as in `company:corelib:329` (I'll assume you're using maven naming here, every java build system under the sun works with maven repos) Have your CI system tag the build in source control as well as releasing the maven artifact; both with the same number. You also want to make sure this version is exposed by the manifest, and ideally that you have a way to query the component at runtime (RESTful endpoints are good for this). That way it becomes easy to trace problems in production/staged environments back to the specific code in use. Don't use snapshots, do everything with these numbered releases. It makes your build system happier (especially if you ever work offline), and it just makes the environment a lot more stable. On 18 January 2014 12:48, Emilis <[email protected]> wrote: > Assuming that you have no artifact versioning at all, there are a couple > pretty obvious advantages in the "old school" system: > lets you quickly find out what code is deployed > lets you switch deployments easily in case of mess up > > That said, this might not be as useful in small companies. > > > On Saturday, 18 January 2014 05:41:38 UTC+1, rakesh mailgroups wrote: >> >> Hi all, >> >> wanted to pick your brains about something. >> >> A fellow (new to the team) developer was shocked we did not version >> our release artefacts. >> >> We pretty much just give the latest war file (with the same name each >> time) to the infrastructure team to deploy. >> >> Is that really bad? >> >> Its not that I'm completely ignorant to the practice, its just that >> doing <major>.<minor>.<patch> naming of the artefact seems to be a bit >> old school. >> >> Companies who sell software for example (like Oracle) where there is >> multiple versions of their product in the wild and its possible that a >> particular customer will need a specific patched version. >> >> We could do it I guess at the cost of a little bureaucratic overhead, >> but it would be good to get some opinions so I'm armed at the next >> retro as to why we don't do it. >> >> Cheers >> >> Rakesh >> > -- > You received this message because you are subscribed to the Google Groups > "Java Posse" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/javaposse. > For more options, visit https://groups.google.com/groups/opt_out. > -- Kevin Wright mail: [email protected] gtalk / msn : [email protected] quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <[email protected]> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
