Skip to main content ↑ ↓
On the release cycle Started by emanuele · · Read 31287 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

On the release cycle

I was playing again with the admin_info_files and so I had to think a bit about what we want to do with the release cycle, in particular about what versions we want/can support[1] in particular.

I'm not particularly attracted by the "support forever" policy, so I would support only the latest version released.
As an example: I would release security (i.e. micro) updates for 1.0 only until 1.1 is released, at that point, 1.0 is considered unsupported and security fixes are released only for 1.1.
Of course if someone is so happy about it, he can just take some time and make the patch to fix it, but I wouldn't want to spend much time on a "old" versions.

What do you think?
1 What I mean with support is for which version/s we are going to release security updates↵
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #1 –

QuoteI would release security (i.e. micro) updates for 1.0 only until 1.1 is released, at that point, 1.0 is considered unsupported and security fixes are released only for 1.1.
yep, agreed.
Thorsten "TE" Eurich
------------------------

Re: On the release cycle

Reply #2 –

That's good policy. It will encourage the admins to upgrade for better features and security.

How will the updates applied to the existing installation? Just replace and run upgrade script or package installation like SMF2?
192.MY.ID: Forum ISP Indonesia.

Re: On the release cycle

Reply #3 –

I'm not entirely sure yet (maybe others have a more clear view), I aim at a simple: click->upgrade.
At the moment the remote update is still not yet fully in place (I mean like SMF with a warning in the admin panel where you click, the new version is retrieved and installed), but I hope that any kind of update should be doable like that, maybe the first time/s it will require to manually download the package and apply it, dunno yet.
From beta to RC to final, probably a "upload-and-replace" will be the way (even though I may try to experiment the script I made a while ago and create packages...dunno, depends also on the complexity of the changes), but there is still some time. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #4 –

Quote from: emanuele – I was playing again with the admin_info_files and so I had to think a bit about what we want to do with the release cycle, in particular about what versions we want/can support[1] in particular.

I'm not particularly attracted by the "support forever" policy, so I would support only the latest version released.
As an example: I would release security (i.e. micro) updates for 1.0 only until 1.1 is released, at that point, 1.0 is considered unsupported and security fixes are released only for 1.1.
Of course if someone is so happy about it, he can just take some time and make the patch to fix it, but I wouldn't want to spend much time on a "old" versions.

What do you think?

I would agree...
1 What I mean with support is for which version/s we are going to release security updates↵
 

SPLIT: buglet/feature footnotes [was: Re: On the release cycle]

Reply #5 –

One or more of the messages of this topic have been moved to Bug Reports.

http://www.elkarte.net/community/index.php?topic=943.0
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #6 –

I'm loving the way Elk allows to split topics! :D

Back on topic, okay, supporting only last version makes things like upgrading much easier.

The second thing is the release frequency.
This is tough.
At the moment I think we can afford a 1 year release cycle for moderately major features, for example we could decide to:
  • feature freeze in September,
  • release a beta in November,
  • second beta in January,
  • release candidate in February,
  • final in March.
And then start the round again.
This would leave at least 6 months of active development each year, not that bad, considering that "minor" things can be sneaked into betas as well (we did that lol) and with the consolidation of the codebase, development should become easier (hopefully, if it is not it means we did something wrong and we have to fix it!).

That leads me to another point: versioning.
Spuds pointed once to http://semver.org/ so I suppose he thinks this is a good way, and I agree.
Now, we'd have to define what "API" means for Elk.
Elk doesn't have exactly APIs, so we could consider "API" anything that makes it work (i.e. functions, hooks, templates).
The changes I have in mind for 1.1 may already break this versioning scheme, *but*, if it will be possible to implement them in a backward compatible way, we could use a scheme like that:
  • develop 1.0
  • develop 1.1 changing architecture, but introducing "layers" of backward compatibility,
  • develop 1.2 changing architecture, but introducing "layers" of backward compatibility,
  • develop 1.3 changing architecture, but introducing "layers" of backward compatibility,
  • develop 2.0 <= would simply mean: we reached a level backward compatibility is damaging[1] our code, let's take 1.3, drop all the backward compatibility and add new features.

    Today I'm in a good mood! LOL
1 maybe "damaging" is a bit harsh, let's say make complex to add new features or simply looks stupid maintain it further↵
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #7 –

That cycle makes sense to me, I don't realistically see things going any faster than that, also given that between . x releases we have to account for . . x  patches which take some effort.  

For 1.0 we probably had a solid year of very active development to get to B1, granted we had a lot of ground to cover and yes we still have moar to do :D  But as a general thought exercise a 1.1 should be a no sooner than a year out from 1.0.

I do like the Semantic Versioning "reasoning",  and I think it what people generally expect of software.  I don't expect when a 1.0.1 arrives that I need to get all new addons.  Even a 1.1 the vast majority of addons should still just worktm.  Of course we still have the baggage of potential source edits that are by nature fragile, but I think you know what I mean.

For a 2.0 .. we remove anything we mark as depreciated in 1.x branch, or anything that was there for a  (and we need to be good about tagging things as @deprecated).  Other things in addition to API changes are minimum requirements like 5.1 to 5.4  O:-) and maybe browser support (drop semi old browsers) and other such things?

Re: On the release cycle

Reply #8 –

Cool, cool!

Yes, semver reasoning is absolutely right!
In our case I think we have to pay quite a bit of attention to all the different aspects we have.
I wouldn't consider code edits as "API", and that should help in phase out that habit.
But all the template names are kind of API-ish I think, and also the layout, for example I wouldn't expect huge changes in the default theme from 1.0 to 1.1.

php and browser supports...well, yes, or so.
For example: if Elk will go through 3 minor releases before switching to 2.0 (like in the example I did before), it would mean 3 years from now: 2017. In 2017 I expect to have Chrome 100, Firefox 35, php 5.8 out, 5.9 in development and 5.5 EOL'ed (according to their release cycle process). And Elk would still support php 5.1, IE8 and Firefox 26?

I'm in favour of a more flexible approach to minimum requirements, also because I would avoid situations like the one with SMF where php 5.5 was going to created a quite huge mess in the error log.

Unless you mean take it "the other way" and if we change the minimum requirements would "just" result in a bump of the major version.
Yes, because when deciding the release cycle there is the usual problem of defining what is the cause and what the consequence, so:
  • versioning is the "cause" and we decide requirements based on that, or
  • versioning is the "consequence" and we pick the version number based on the design decisions?
It's a mixture I suppose... :P

And I didn't even drink today!! LOL
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #9 –

QuoteUnless you mean take it "the other way" and if we change the minimum requirements would "just" result in a bump of the major version.
Yup more this ... Right now I have a hard time believing a 1.2 would not "up" the min requirement and therefore really be 2.0 .. meaning 1.0 really will only get one bump + patches.

In a 1.1 we will continue to consolidate sub functions, we did a great job getting query's out of the controllers, and reusing them but I know more can be done.  Many functions inside of the same sub are so similar that they can be combined.  Across subs gets a bit messy but there is opportunity there as well.   Anyway when we combine we either remove the old function or mark it depreciated and all it does is forward to the new consolidate one (comes down to, do we think its removal breaks addons?).  In 2.0 they are just fully removed, less clutter etc.

Re: On the release cycle

Reply #10 –

Another thing that @forumsearch0r highlighted on IRC, we should also pay attention to language strings: change them "frequently" means more work for who is translating.
The best would be to declare a "string-freeze" period before the release where we will not change strings unless absolutely necessary. For example, assuming we aim to have 2 betas only, the release of the second beta could be a good moment for that (the code should be stable enough at that point).
Even now (except for the last minute surprise merged just today :P), we should try not to change text strings any more.
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #11 –

I second that request.
-

Re: On the release cycle

Reply #12 –

I recommend string freezes for Release Candidates, but not betas.

Re: On the release cycle

Reply #13 –

yeah, that's one of the benefits with transifex... keeps track of changes.  ;)
Thorsten "TE" Eurich
------------------------

Re: On the release cycle

Reply #14 –

TE, you that are the King of transifex, I didn't see any was to let him handle the different names of the different translations (I mean the language into the file name).
Maybe I'm overlooking something, do you know if it is possible or it would be necessary to drop it?
Bugs creator.
Features destroyer.
Template killer.