Skip to main content ↑ ↓
Topic: On the release cycle (Read 22430 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: On the release cycle

Reply #15 –

Quote from: emanuele – 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?
Yep, IIRC that wasn't an UI option but could be done with the client.. I'm testing right now.
Thorsten "TE" Eurich
------------------------

Re: On the release cycle

Reply #16 –

Hi, new here so I guess bad form to post disagreement right off, but I think dropping support for the old release as soon as the new one is out is an awful idea.  It might seem great if you're an active developer, or a techie in general, but for the average forum user that's likely to be a huge turn off.

I think you should support one version back for at least a few months after the new version has left beta.  Many people will not install a beta release, and honestly you probably don't want every active forum out there running on beta code.  So people need to time to make the transition, port over any custom themes, code etc. to the new version.  Things like that.

To just say hey, version 1.1 is out today, upgrade immediately or else seems likely to be a pretty big turn off.  Especially for large changes in the code or theme.

Just something to consider.

Re: On the release cycle

Reply #17 –

Being unsupported does not mean a person is out of luck just because a new version came out. It means developers don't have to waste time writing fixes for old code. Someone is certainly free to send in fixes, but it's not required for anyone to do so if the new version is already released. New version meaning a final product, and not a beta or alpha.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: On the release cycle

Reply #18 –

I realize you mean drop support once the new version goes final.  But say a security bug appears one day after the new version is released.  Anyone who isn't ready to upgrade in a few days has to rush to get there or live with the bug or hope some developer is willing to take the time to patch it?

Seems harsh to me.

Re: On the release cycle

Reply #19 –

What's the difference between a day and a few months? There are always going to be users who are sitting on a version that is unsupported and has possible security issues. The instance you reference is likely not going to happen. Sure its possible, but that's a pretty good shot in the dark that something is going to happen the day after, or even the month after. At that point people should be upgrading anyway. That's the risk the site admin takes though in using all 3rd party software. Either way though, I'm ok with whatever they decide. I'm not one of the active developers here, and wouldn't want to force them to use their free time in the way I think best.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: On the release cycle

Reply #20 –

I thought I posted that a long time ago.... :(

Quote from: scripple – Hi, new here so I guess bad form to post disagreement right off,
No problem, it gives me the opportunity to write a long post. :P

Quote from: scripple – I think you should support one version back for at least a few months after the new version has left beta.  Many people will not install a beta release, and honestly you probably don't want every active forum out there running on beta code.
Nope, I don't want to see betas on live sites[1].

Quote from: scripple – but I think dropping support for the old release as soon as the new one is out is an awful idea.
[...]
So people need to time to make the transition, port over any custom themes, code etc. to the new version.  Things like that.
[...]
To just say hey, version 1.1 is out today, upgrade immediately or else seems likely to be a pretty big turn off.  Especially for large changes in the code or theme.
Sorry if I split a bit your message, it looked to me these three pieces should be answered together. ;)
Your last paragraph means you have a certain idea over the release cycle that apparently is shaped over SMF releasing model: break a lot at each and every release.
That is hopefully not the path I see for Elk.
Unless we all go nuts, anything working on 1.0 will work on 1.1 as well (if it follows the guidelines, of course we can't guarantee code edits will work, but code edits are a last resort that is going to be phased out "at some point", so it's against guidelines).

That said, it just moves the focus on another step: 1.x to 2.0.
In this case, obviously any backward compatibility may (and likely will) break.
It's not that 2.0 will be out the day after 1.1 will be out stable, it will take at least one year.
You could argue people (developers/themers) won't know how 2.0 will look like on development day 1 as well . True: if 1.1 is released the 31st March 2015, the 1st of April nobody will know how 2.0 final will look like. But for example, 1.0 beta cycle started in December last year: since then, almost all the API have been stable (I don't remember any change in hooks apart from adding a couple or name functions... okay I may have changed one O:-)).
You could argue it's not a lot of time, December-March are 5 months. True again, but I highly doubt ElkArte will be overhauled in a bunch of months as well: there will be several incremental changes, the "jump" in number will be because backward compatibility will not be guaranteed [2].
Yes, I realize there are also changes that may break stuff without the option for a solid backward compatibility[3].
Last but not least: I hope everybody agree that a new theme is for 2.0 and not for 1.1. ;)[4]

This was all about development: just to give you the right background Elk is moving on (or at least I hope it is moving on) and highlight that developers (and please not I'm using this term to identify but people working on the "main" code and anyone out there working on addons, both are developing something, and themers, all of them are worth the name developers. ;)) should have quite a bit of time and all the tools to do a smooth transition.

From the admin point of view: of course an upgrade takes time. WordPress upgrades 3 times a year, any kind of upgrade is basically a "click here and wait". This is my personal goal for ElkArte. It will not look like that on 1.0. (personal road map =>) It may not look like that for 1.1. It should looks like that for 2.0. It must be like that for 3.0 (<= personal road map).
1 even though, considering the approach we took on 1.0, have a beta wouldn't be a big pain: "upgrade" always just meant to replace the files with a new batch and nothing more.↵
2 for example Joshua is working on 1.1, introducing some deep change in the way actions, controllers, functions and the theme work, but anything working with 1.0 will work in 1.1 as well (otherwise it could not be called 1.1), for 2.0 the only thing to do is remove what keeps things compatible with 1.0)↵
3 for example I know since a couple of months I'll have to change the name of a column of the database the moment 1.1 development starts.
I can't help it, and it may lead to some pain if anyone will write custom code (i.e. queries) involving that db table, but I didn't want to change the db schema while in beta, so I postponed the change for a "next version".↵
4 Even though there may be a way to have that too, I have to think about it. :P↵
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #21 –

Quote from: emanuele – 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.
Pretty bumb for that one. We did quite a bit of changes recently, ehh... I know someone would say s**t happens, there were reasons and so the changes have been merged.

Now we are close to the first RC, I don't know (yet) what you all think, but from my point of view, "RC" means: from here to final the only change should be version number (unless of broken stuff of course).
So, setting the baselines, to me "broken stuff" means:
broken code (e.g. call to undefined function, broken queries, etc.);
 any (unexpected) error in the log (that includes undefined variables/indexes);
in javascript anything that prevent a feature to work (e.g. some javascript that blocks a button), I'd say case-by-case for features meant to work with js, but falling back to non-js because of errors;
 css in themes means very ugly stuff (i.e. a misalignment of 1px doesn't count as ugly in most of the cases)
in strings I'd say sentences with wrong meaning or wrong grammar, typos and improvable sentences may have to wait the next release.
Of course these are my standards, others may disagree, so this is here for discussion, not a diktat.

The repo is a slightly more complex beast to deal with.
At the moment we have two branches:
 master where 1.0 development is going on,
* development where 1.1 development is happening.
There are few possible alternatives, and I'm not sure which one is the preferred.

We could:
  • branch from master a RC1.0[1], merge development into master and continue the work on master;
  • continue to use master for the 1.0 line until 1.0 is final, merge master into development and continue there the 1.1 development, once 1.0 is in its final state, start following more strictly the original model proposed by @TestMonkey.
  • rename master to 1.0, rename development to master
  • rebase development on top of master (that would be a pain)

I'd be tempted to say 2.
It keeps development not exactly "in front of everyone"[2], but should be quite organized.
1 has the drawback of bring into the history tons of duplicated commits (i.e. all those merged "back" into development from the current master in the last months).

Opinions?
Ideas?
1 to be used for the small fixes needed before the release↵
2 Even though I seem to remember there is a setting at github to decide which branch is the "active" one↵
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #22 –

 Spuds is very sad that he can't continue to break 1.0

I agree with your RC thoughts, plus any security items should any be found/disclosed/etc.  Its really a bit of a waiting game, a lot of the features have been tested since we have been running the code on the site for some time, but there are a few areas that have not gotten a lot of live testing and frankly may never.

I'd think option 2 above would be right, the Master branch should contain the latest stable code, official release stuff.  Development should be just that, and should be rebased (again  O:-) ) to the RC level.  We then use that for our 1.1 work. 

I'm not sure we need all of the finesse of the model given in the link, maybe.  We could have the hotfix branch for 1.01, 1.02 so work there could be picked back in to master and development should a hot fix be needed.  Not sure we need the release branches stuff, seems complicated to remember where all the stuff is and why.

Re: On the release cycle

Reply #23 –

Quote from: emanuele –
* in strings I'd say sentences with wrong meaning or wrong grammar, typos and improvable sentences may have to wait the next release.


First appearances are everything. Poor wording, typos, etc. make for a very bad first appearance. Now, the programmers will all understand the 'why' but the average user will wonder why the errors in the wording. I would think that prior to a RC1 release that the strings should be correct to as great of an extent as possible. The strings are after all, how the forum communicates to the Admin and to the user.

As for minor adjustments in pixels, color and alignment, that does not seem as critical to me unless the alignment affects how the user types something in.

Re: On the release cycle

Reply #24 –

Quote from: scripple – Hi, new here so I guess bad form to post disagreement right off, but I think dropping support for the old release as soon as the new one is out is an awful idea.  It might seem great if you're an active developer, or a techie in general, but for the average forum user that's likely to be a huge turn off.

I think you should support one version back for at least a few months after the new version has left beta.  Many people will not install a beta release, and honestly you probably don't want every active forum out there running on beta code.  So people need to time to make the transition, port over any custom themes, code etc. to the new version.  Things like that.

To just say hey, version 1.1 is out today, upgrade immediately or else seems likely to be a pretty big turn off.  Especially for large changes in the code or theme.

Just something to consider.

I definitely agree with that. Especially if I have a mod installed that makes deep code changes, it's probably not going to allow me to upgrade. At some point, some new version will break my code, and then I'm out of luck. I either have to spend the time (or the money, if I don't have the expertise) to change the code, or hope that my board doesn't encounter any bugs or security holes in the meantime.

Honestly, you should never leave security holes unpatched, even if they're on an old version. If someone's using it (yes, it might be dumb in your opinion, but they're using it) and they get hacked, they're not going to think fondly of Elk, and your reputation will suffer. I don't want to see Elk's security reputation turn into the lolfest that phpBB is.

Re: On the release cycle

Reply #25 –

Quote from: Aggelos –

Quote from: emanuele – * in strings I'd say sentences with wrong meaning or wrong grammar, typos and improvable sentences may have to wait the next release.

First appearances are everything. Poor wording, typos, etc. make for a very bad first appearance.
And my wording was poor as well.
The sentence was to be read:
* in strings I'd say sentences with wrong meaning or wrong grammar should be fixed, while typos and improvable sentences may have to wait the next release.

Quote from: Aggelos – Now, the programmers will all understand the 'why' but the average user will wonder why the errors in the wording. I would think that prior to a RC1 release that the strings should be correct to as great of an extent as possible. The strings are after all, how the forum communicates to the Admin and to the user.
That's what I actually said: until RC1 is out strings can be fixed. When RC1 will be released, then stricter standards should be applied in order to decide what should be pushed and what can be delayed.

The point is that a "release candidate" should really be exactly the final version just with a different version number. Any change in the code may affect other places, and change anything in code that is considered ready for release is a risk no matter what (see issue 1601).
Yes, language strings are less likely to break anything, but change a string affects the work of people working on translations, delaying the release of any translation. Even fix a typo means that people will have to review their translations, and that is an annoyance.
Have the fixes in the "next version" doesn't necessarily mean 1.1, it may be a micro release to fix other bugs.

Quote from: Aggelos – As for minor adjustments in pixels, color and alignment, that does not seem as critical to me unless the alignment affects how the user types something in.
And a themer would point out that the theme is the way the project presents itself to the world and a one pixel misalignment would demonstrate sloppiness.

Yes, all this is true, problem is: at a certain point the code should be declared "stable" enough to be used in production.
Note that "stable" doesn't mean "perfect", it just means there are no known problems that prevent usage on a daily basis.

Quote from: Eliana Tamerin – I definitely agree with that. Especially if I have a mod installed that makes deep code changes, it's probably not going to allow me to upgrade. At some point, some new version will break my code, and then I'm out of luck. I either have to spend the time (or the money, if I don't have the expertise) to change the code, or hope that my board doesn't encounter any bugs or security holes in the meantime.
I see two problems here.
Let's start with the easy one: you are thinking of Elk as SMF. Elk is not SMF. As pointed out by Spuds, Elk should aim at semantic versioning. I'm not sure 1.1 will be able to be fully backward compatible with 1.0, but I'm sure I'll try to keep it backward compatible as much as possible.

Then the second problem: let's revert your thought on people contributing to ElkArte: it means that ElkArte has to support anything that people are using for an indefinite amount of time[1], spending time (or money) in order to give you the possibility not to spend your time (or money).
Unfortunately someone has to spend time (or money) on coding, there is no way around it.
This is free software, the moment you are in front of the decision if you want to keep the version you want to use or upgrade, you are free to do two things:
1) spend time/money to upgrade,
2) spend time/money to fix what you have.
Nothing prevents anyone from submitting a patch, or even taking responsibility to maintain the 1.0 version for an indefinite amount of time.
I'm just saying that me (emanuele) doesn't see the point in declare that Elk is going to support each version forever, because this will just be a lie, and I don't want to lie. At some point you will be forced to upgrade if you want to keep your forum secure and in working conditions. You may not like it, but this is the truth.

Quote from: Eliana Tamerin – Honestly, you should never leave security holes unpatched, even if they're on an old version. If someone's using it (yes, it might be dumb in your opinion, but they're using it) and they get hacked, they're not going to think fondly of Elk, and your reputation will suffer.
If someone wants to blame ElkArte, they will anyway (anyone read the fuss about SMF and Avast recently?).
I don't want to see Elk drown in multiple versions support without the necessary man power[2] to support that distribution model.
Of the most popular free scripts I kind of know, there are 2[3] that support multiple versions at the same time: Joomla! and MediaWiki. Both are supported by quite solid communities and foundations. We at the moment are not (again pragmatically speaking): there are two/three people working rather constantly on code and features plus other 5 or 6 jumping in from time to time.

That said, I'm not saying a patch for a "previous" version will never be released, that may happen, as I said it's free software and it's possible, I'm just saying: do not expect it to be the routine (at least not from me[4]).
1 And yes, I know it will end up in "indefinite", because implicitly in the objection you are bringing to the table, you are saying that if you are using the line 1.x you may not want to ever upgrade to 2.x because your code will break. ;)↵
2 Yes, pragmatically speaking, it all comes down to the number of people working on the code.↵
3 Yes, in theory SMF as well, but they finally realised that support multiple versions is far from optimal.↵
4 Yes, I'm a selfish deranged (<= that's not what I wrote! lol). :P↵
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #26 –

Then may I suggest building in an auto-update feature into Elk? If newer versions like 1.1, 1.2, etc will slide gracefully on top of 1.0, then why not just force everyone to update? Either do it automatically (default to on, which no on should change unless they're retarded) or force admins to do it the next time they log into their admin panels after the update.

That way, no one is ever on an outdated version (until the jump goes from 1.x to 2.0) and Elk is free from bad reputations due to security holes (no one will ever prevent antivirus software from gently caress fudge nuggets up, sorry to say it).

Re: On the release cycle

Reply #28 –

Quote from: emanuele – http://www.elkarte.net/community/index.php?topic=732.0 O:-)

The interim measure could be as I described, merely force admins to upgrade the next time they login. Some people will whine, but it'll get them in the habit of not making code-breaking changes and using hooks instead.

Re: On the release cycle

Reply #29 –

hmmm... personally I would run away from a software that forces me to upgrade.
Not even Microsoft or Apple force people to upgrade operating system. :-\
Bugs creator.
Features destroyer.
Template killer.