On tagging and regular version releases

[Marcus Nyeholt]

With the idea of a more structured module management process gaining ground, I thought it'd be a good time to discuss a related maintenance issue, which is knowing when you might need to upgrade (as an end user) or knowing when to release an update (developer). 

At the moment many modules appear to suffer from a lack of 'recent' stable releases; this isn't to say they're not stable, just that the most recent tag is very different from trunk or whatever the current 'stable' branch is. It's also difficult to know when a new stable SS release will be cut - I'm sure there's a methodology behind it, but as a site maintainer, it's difficult to plan around when that might be and to organise things appropriately. 

Something I'm going to start doing personally is to tag my modules at regular intervals (probably monthly) IF there are any differences between the current development branch and the last tag. This way anyone using them knows that at the end of every month there will be a new stable release made; it also means that as a developer, I know that if I want to have something in a release, I have a specific date to get them done by. 

How do other people currently manage their 'release' process? 

Marcus

[Hamish Campbell]

On Feb 18, 1:42 pm, Marcus Nyeholt <nyeh...@gmail.com> wrote:
> Something I'm going to start doing personally is to tag my modules at
> regular intervals (probably monthly) IF there are any differences between
> the current development branch and the last tag.

I feel like that might place a burden on your users if they have to
figure out if the new release actually contains significant updates or
not. It's fair to say that some modules are developed on a fairly
haphazard time-frame and can go months with only minor fixes and
changes before a flurry of activity.

Basically it's up to the module maintainer to do it right and tag
appropriately. Some people are certainly much better at it than
others.

Can I ask which modules you've having issues with in particular?

Hamish

[Marcus Nyeholt]

I feel like that might place a burden on your users if they have to
figure out if the new release actually contains significant updates or
not. It's fair to say that some modules are developed on a fairly
haphazard time-frame and can go months with only minor fixes and
changes before a flurry of activity.

That's actually the point - there may be small fixes added to a module haphazardly, but for whatever reason no 'stable' tag is created because it's not seen as having significant enough work added into it (or that there's no tagging process in play). 

On the other hand, for a module that has lots of development (something like sapphire or cms), the length of time between tags means there could be quite a high number of changes that make an update more likely to be problematic. sapphire and cms aren't too bad when it comes to tagging, with it normally being about 6-8 weeks between stable tags. 

Isn't the whole point of version numbers meant to convey to users whether there are 'significant' updates in a release? Taking SilverStripe's major.minor.micro structure

Major - There may be fundamental underlying repository changes, requiring development time to upgrade codebases - modules will probably break nastily. 

Minor - Most things will probably work but there will likely be new features to take advantage of. New apis and functionality will likely have backwards compatibility worked into things to limit the impact for end users, but there might be some code breaking

Micro - Should mostly be a case of applying the update and running dev/build, no big new features, largely bug fixes. 

Can I ask which modules you've having issues with in particular?

It's not a particular module really - it's something I'm thinking of from a maintenance point of view for managing the client codebases we have. If I have a script that can go into each project, see which version of a module it's using, check what the current latest stable version is from the remote repository (or central module management repo), then alert me that it's different, doesn't help as much if it's running only against commit ids. 

And because I'm just as guilty of not tagging modules as regularly as I could through forgetfulness or "I want to add more stuff in before doing so" and never getting around to doing so. A simple script that I run monthly that will automatically scan my github repositories for changes since the previous tag is relatively simple to write. I'd imagine manually managing the process would be a little bit more of an overhead and make the process a little more painful. 

Marcus

[Ingo Schommer]

I think lack of regular releases for "smaller" modules become less of a problem

for us now that we have piston to update at well defined points in time

(when we can review the commit list). That doesn't scale of course,

and a properly managed deprecation cycle, upgrading guide, changelog

is preferrable :) On that note, there's some good instructions

in the "Producing OSS" book: http://producingoss.com/en/development-cycle.html

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

---

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

in...@silverstripe.com

Phone: +64 4 978 7330 x 42

Skype: chillu23