Author Topic: Version numbers (Read 1287 times)

jalama · August 16, 2011, 07:03:37 pm

The versioning labels don't make sense from my perspective it's based on what we feel is a big enough release to up the version number. I would like to talk about constructing logical terminology for what constitutes a minor or major release. The end goal here being to get feature releases away from bug fix releases so they can go out faster (ie as critical and blocker bugs come in and are verified) and so administrators know which versions they can wait on in order to provide their users with some stability. I would propose something like this:

1.) Major releases 3 to 4 (3.x.x to 4.x.x) for major features updates preferably only to components or only to core

2.) Minor releases, 3.x to 3.y (ie 3.5.? to 3.6.?), for smaller features or upgrades upgrade to core to handle features coming in the next major release (though I think this level should really just get eliminated altogether as what constitutes a major or minor feature change is subjective in many cases).

3.) Bug fix releases 3.5.x to 3.5.y (3.5.0 to 3.5.1) for bug fixes and security patches only. (Which means no new features at this level, unless there is 100% test coverage for them)

To be honest I think we should dump the third number altogether and have just x.x, and have only feature releases and bug/security fix releases but I don't want to confuse people too much

Donald Lobo · August 16, 2011, 08:55:32 pm

you've raised some valid points which we've been thinking about while figure out the "State of Civi" for the London CiviCon. I'll throw in a few more data points for folks to think about and what/how we can change to improve things going forward:

1. While the alphas/betas get fairly decent testing, and the unit / web tests are getting better, we do need a couple of final releases 3.4.1 / 3.4.2 to catch some of the more bigger issues (especially with some upgrade issues / non-core stuff)

2. A large part of the consulting work (which we do to sustain the project) and MIH work, want the feature yesterday and in a stable release. We compromise and add the feature to the next point release thus helping improve CiviCRM and giving the "funder" what they need. If i had to guess, if we said this will come out in the next release (2-5 months from now), i suspect a significant % of the funding would disappear. To make it concrete, a lot of the 4.1 MIH's have been pulled into 3.4 (which in turn has pushed back the launch of 4.1)

3. Its hard to make a distinction between a critical bug, a bug, a missing feature and a feature. Its so dependent on the context. Its also because the final package encompasses so much functionality

I do think that we can figure out a better and more improved solution. But we should consider some of the above and figure out how they fit in.

lobo

jalama · August 18, 2011, 08:33:54 am

Yea I never thought about it but to mak an analogy to the Non-Profit world the MIH stuff does create the same problem as consulting of making it an even more funder, vs community, driven project (that's the the right way to say that as funders are community members also). The unintended consequence being deadlines really can't slip which pushes things back even further for the new release.

So what about moving Core team consulting projects into modules/extensions with only small tweaks to core to make aforementioned modules them work getting rolled out in minor releases (minor by my original definition)? At a later date (if deemed acceptable) those projects could get rolled into core in a major release (ala Drupal). Which of course makes it harder to sell to the client ...

I understand the subjective nature of critical/major/minor bugs, features, but I think that's just something that has to get worked out over time and a good, publicly documented, decision making process is going to be our best bet there.

Donald Lobo · August 18, 2011, 02:28:29 pm

I think as we get more developers from outside Civi LLC contributing to core, we'll move towards the model of building things outside core as modules / components / extension etc.

However, its a fair bit of work to move drupal code into civicrm, and as the event_discount module shows, its hard to get a lot of funding to move something like this into core (where it would be a good addition, IMO)

how does drupal decide what to fix in 7 vs punt to 8?

lobo

xavier · August 18, 2011, 02:34:13 pm

IMO, the problem is that civi doesn't have a system for modules, you rely on the CMS system, so when we dev something outside of the core, it's drupal only or joomla only.

Not sure at all how to solve that, no idea how complicated or even possible to hide the differences and simply have a civicrm module that works everywhere.

X+

davesage · August 18, 2011, 03:16:25 pm

We know there are plenty more drupal modules than Joomla and I understand the historical reasons behind that but please don't do anytihng to make the situation worse, anything that can bring functionality cross platform more easily (or a-platform) would be welcomed, this would encourage more Joomla devs to contribute and help move drupal stuff cross platform surely.

I keep seeing good stuff and then realise it is drupal only, a civi-module idea might work but not sure how you would do it cross platform.

I know Joomla people need to step up and contribute (I wish I could more - in terms of better coding skills and time) but there is an uphill struggle to catch up.

Just my two penny worth,

Civi is ace though :-)

jalama · August 19, 2011, 06:44:22 am

When it come to consulting work I'm not sure I think that's an issue the client has likely already chosen a CMS.

To be clear I'm not in anyway advocating that new functionality be single platform but I do believe that the MIH and consulting work should not be a hinderance to a logical versioning and release scheme. The reality is the Core team has in the past given a discount to client's whose work is to be part of the code base (presumably if it was deemed an improvement). The client needs to accept that part of that price is their work is being integrated with other features in a particular release and cannot come before making sure our releases are stable and not harming other installations.

Doing the work in a module/plug-in/add-on/extension (or whatever the heck people want to call it) has two benefits. Primarily it doesn't impede CiviCRM's development but secondarily it means the entire CiviCRM ecosystem of users is not testing the code generated for a single client

Donald Lobo · August 19, 2011, 09:29:04 am

a few thoughts and comments:

1. Today, if i had to guess: 60-80% of feature adds / improvements come in via either an MIH or a consulting request thru CiviCRM LLC. This is the main bread / butter / water / engine (use your favorite expression here), that drives civicrm forward.

2. Most of the above work that gets integrated has been requested by quite a few other folks in the community and as such is of general usage. Client specific work, typically goes in a separate module

3. I think the practice of putting in new features in a point release is both good AND bad. But, i do agree that we need to think and figure out a good medium that works for most people

4. Creating a civicrm plugin scheme, at this point does not seem worth it (if we do, it should be after the DB / Form / PEAR upgrade)

lobo

CiviCRM Community Forums (archive)

News:

Author Topic: Version numbers (Read 1287 times)

jalama

Version numbers

Donald Lobo

Re: Version numbers

jalama

Re: Version numbers

Donald Lobo

Re: Version numbers

xavier

Re: Version numbers

davesage

Re: Version numbers

jalama

Re: Version numbers

Donald Lobo

Re: Version numbers