There are reasons why an institution may want to periodically update to the latest code on master as compared to waiting for released versions.  This page attempts to elaborate on some of the issues and aspects to allow institutions to decide what works best for them.  

Regardless whether you update to the latest code (e.g. the latest on master) or wait for released versions, you should still build and test in your development or test environment before releasing changes to production.

Updating to master

Periodically updating to the latest on master has the advantages of:

• Access to new features earlier in the release process.  New feature releases can be many months away depending upon the release schedule (and the impact of switching to semantic versioning, see and http://apetro.ghost.io/uportal-should-semver/)
• Potentially smaller, more frequent updates (depends upon your plans).
• Complete freedom on the timing of updates to match your release schedule
• Some bug fixes may be made as part of other work and deemed difficult to split out or resolved as part of a feature enhancement and thus only exist in master until a new release off master.

Disadvantages:

• You don't have a numeric indication of where you are relative to uPortal's current versioning (it will be 'master on some date and newer than release x.y.z).
• Master is considered (rightly or wrongly) less stable since it is not in use as broadly within the community (which is true for a period of time).  In that context:
  • Commits checked into master are tested by the developer prior to committing and have some level of testing. 
  • You probably are not the first university executing a particular new enhancement (it was developed for or by someone and contributed), but it is not as widely used

Unicon Developers have a policy where possible of developing enhancements on master and bringing customer's forward to master or cherry-picking the changes into the customer's branch to maximize contributions into the community and to be more efficient with client's money (upgrades may come as part of the feature enhancement if it is appropriate and reasonable for the client's situation).

Updating to released versions

Updating to only released versions has the advantages of:

• More conservative strategy.  More Universities might have already gone through the upgrade process prior to your upgrade or are running the released code which provides a sense of security and not being the first to tread a path.  Also you can pick up only bug fixes without new features for a more conservative upgrade path.
• Easier to tell where you are in the released versions (e.g. my university's customizations on top of release x.y.z)

Disadvantages:

• Not all bug fixes make it to patch releases since they may be tied to development done in master
• Less frequent releases