Versioning (5)

So far, as reported here

- Versioning (1)
- Versioning (2)
- Versioning (3)
- Versioning (4)

team that do in-house development and also many other teams have the possibility to adopt practices that extremely simplify versioning for the modules (assembly, jar, dll, exe, binaries in general, excluding executables as web-applications, services and web-services) and speed-up developments: no need for modules to
  • provide support and bug-fixing for previous versions

  • deal properly the beta, release candidate and official release cycles

  • document release notes and track compatibility breaking changes

  • handle friendly version numbers

The practices that permit this enormous simplification are:
  • have all the teams access the same source code repository and build and test C.I. environment

  • always build getting the last versions of the source code (from the head instead of branches)

  • have proper automatic tests coverage on modules and applications and manual testing where needed

  • have applications referencing modules code (instead of binary, so to get always the last version of the modules too)

  •  have teams synchronized time-boxed sprints and releases. Commit only potentially releasable code using feature toggles and latent code pattern

So, where versioning is still useful? That's a topic for the next posts :)



Print | posted @ Sunday, July 25, 2010 10:41 PM

Comments have been closed on this topic.