Semanticmediawiki: Frequent small feature releases

[JeroenDeDauw]

At present we are doing a feature release (a non-breaking, non-purely-bugfix release (like SMW 2.1, 2.2, 2.3, etc)) about once every 6 months.

I propose we adopt a significantly faster release cycle for those releases. Features are available to users much quicker, and users can provide feedback a lot faster (especially when feature toggles (experimental mode) is used). Small releases is one of the XP practices, and is similar to doing continuous integration rather than every-now-and-then integration, in that it makes things go more smooth. Documenting such releases will also be much easier (you don't need to dig in your memory and pull request history to figure out what happened 5 months ago.)

We already have an always working master branch, so this should be easy to do.

How would we determine when it's time to make a new release? The way I've been going about this for extensions and libraries I maintain for several years now is to create a new release as soon as there is added value for the users that would otherwise sit there unused for longer than a certain minimum timespan, say a week. This might translate into weekly releases when development is active. In case of SMW, often this would presumably be the time scale for releases as well.

How would this affect development? Not much. Sometimes you'd need to introduce a feature toggle for something half finished where you would not now. On the flip side of that is that you get much faster feedback, and the satisfaction of people using what you created. Release documentation wise we also go from our current painful situation to something a lot more manageable, perhaps with more user involvement, as users (that don't follow GitHub) can actually see things moving.

Personally I do not feel motivated to put in all the work required to make a professional looking release with how we currently go about it. It's just not fun for me.

[kghbln]

To be honest a feature release every quarter sounds more than good enough for me. We actually were doing this since 2.0 came to live and this release was I believe an exception to this because of the multilingual capabilities which were added. Something like weekly releases sound like a mere horror to me and it would definitely not make me upgrade wikis more frequently. I such a situation I am most likely to skip releases.

[JeroenDeDauw]

If you only want to update your wiki twice a year, then you can still do that. You are not worse off when there are more frequent releases no? You can just upgrade when it is convenient for you, and then look at what's new in the releases since you last did so. Like this you also avoid the situation where your upgrade window is just before an SMW release and miss out on half a year worth of added features.

[mwjames]

Personally I do not feel motivated to put in all the work required to make a professional looking release with how we currently go about it. It's just not fun for me.

Not sure how you want me respond to this! Of course, I can stop putting effort here [0] and then no one is "forced" to do anything, except for an occasional release tag due to translations that are flooding in.

Documenting such releases will also be much easier

Really, I'd expect you still have to:

• Switch branches
• Make a tag
• Change version pointers in the README and on-wiki, Compatibility file
• Change on-wiki pages

This might translate into weekly releases when development is active. In case of SMW, often this would presumably be the time scale for releases as well.

Who is going to do that each week? This seems rather ambitious.

perhaps with more user involvement, as users (that don't follow GitHub) can actually see things moving.

I don't see that happening, given the collected experience here.

Release documentation wise we also go from our current painful situation to something a lot more manageable

How so? Notes will most likely remain the same (at least I'm not in for more hours just because someone feels it needs a more "human" touch, this is a technical project not a literature club).

I propose we adopt a significantly faster release cycle for those releases.

If you think this has some merit and it doesn't bring additional administrative burden, I'm more or less indifferent to this proposal.

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/graphs/contributors

[Fannon]

I'm not sure weekly feature releases are really necessary. Most people don't have the need to move that quickly. Those who really do can also go for the more advanterous master branch.

But for bug fixes it would be very useful to be able to push them out quickly.

[JeroenDeDauw]

Not sure how you want me respond to this! Of course, I can stop putting effort here [0] and then no one is "forced" to do anything

James, I am not criticizing your work. I really appreciate it, and so do many others. If you do not want to go through the release notes and fluff them up, I understand that, and I feel the exact same way.

I do indeed think this does not make things harder to do from the development side. Making a tag and adding a wiki page takes no time. What takes time is the content on the wiki page, which scales with the amount of things that need to go on there, and is affected by how much one needs to dig to figure those out.

Small releases is one of the core XP practices. It got to be one because many smart people found it important enough to put it there. My own experiences with it are also good. We've had one release for Maps a month for a few months now, which is a lot faster than SMW, while a lot less development happens there. Having waited with the release and having done one bigger one would not have made things easier.

This is just a suggestion from my side. One that if followed would make me more active in helping with the release process than when not. If the preference of the other people involves is to not go down that path, especially of those that are most active (ie James), then that's the way it's going to be.

[kghbln]

I think we have established a stable and working release and programming process since this issue originally came up. This is apparently not bringing features frequently but by experience bug fixes and other fluff on a monthly basis. It appears that people can live with this.

Still this issue continues to be on the "release management" work board for future reference.