Update logic

[paula-w]

This issue is a discussion on the update logic.

[paula-w]

zebrahosting wrote:

Nice to see a patch version but aren’t you a bit over enthusiastic with the versioning?

We are currently at stable 2.1.xx. I am at 2.1.0 and your demo site is at 2.1.2 so I would expect a patch file 2.1.0 to 2.1.2

If this is already a test first version for 2.2 I still have the trouble with my stable sites that I manually need to fix the bugs. Without it is not usable. Guess I am not the only one.

But very glad most of the main issues are fixed in a short time span, now we just need a proper way to upgrade stable CRM’s in between.

Bastiaan Houtkooper Zebra Hosting

From: Błażej Pabiszczak Reply-To: YetiForceCompany/YetiForceCRM Date: maandag 10 augustus 2015 12:59 To: YetiForceCompany/YetiForceCRM Cc: Zebra Hosting Subject: Re: [YetiForceCRM] [BUG] creating records (#1739)

You should never overwrite the gitdeveloper files, we introduce tons of changes there [at the moment we got the 2.1.39 version], doing this might solve one or two problems and generate several new ones, which you won't be able to handle.

A test upgrade package for the current version you can download here [test version]: https://github.com/YetiForceCompany/UpdatePackages/tree/developer/YetiForce%20CRM%202.x.x/2.1.0_to_2.2.0/zip

[paula-w]

bpabiszczak wrote:

I don't know why there's a different version than 2.1.0 in the test version, I'll find it out tomorrow because I don't remember ordering the update for the test version to anyone. The link to the update package you received is the developer version and it's used to update the system from v2.1.0 to v2.1.x if someone needs that [for example you need an update to v2.2.0 because some functionality is not working for you]. The update package you have the access to is the test developer version [we don't officially post it anywhere, because the official version will be available in September]. This package is made on an incremental basis, which mean that every couple of days the programmer receives the changes that were accepted and they appeared in the Master version. It received the 2.2 version because v2.1 was closed! We won't add any changes to it; even if it included a modification of a single line of the code it would also be marked as v2.2 [we could at most call it alpha or beta instead of RC, maybe then the name wouldn't bother you]

I don't know what errors you're talking about, the only errors known to us can be found here: https://github.com/YetiForceCompany/YetiForceCRM/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22YetiForce+2.2+GA%22+label%3Abug and none of them are critical for the system's functioning.

Unfortunately I don't know what your issue with updates between the stable versions is, but it seems like it's caused by misinterpreting the update package, to which you received the link from us, you treated it as a stable final version but it is just a test version prepared for you, among others.

[paula-w]

zebrahosting wrote:

OK understand that you don't want to follow international standards that minor updates keep the same major number. I'll live with that.

I will keep testing your 2.2 dev updater on my dev versions. Thanks for the explanation.

I don't overwrite gitdev versions, my testing is always with a clean install once in a while and double checked with Yeti github versions.

The main issue remains for me: how to deal with all the bugfixes right after the stable version has been publicized. And yes it is unusable for us when there are still a few crucial bugs. Of course that happens and will be different for everybody, but we use the filters , mailtemplates etc extensively and it is breaking our workflow. I am confident and see that most of it is fixed in no time but still there need to be a better way of 'fixing' / updating a stable version. Now I add the fixes manually one by one. Sometimes in code, sometimes replacing the file. Don't think you can expect that from every client. At the same time it is good if users get small incremental updates ones in a while. In this case I would say two weeks after the stable release there could be a patch file with the fixes up to that date. If you use the move to 2.2. version number the next update will not work. So still wondering how you will solve this.

[paula-w]

SkavenKF wrote:

Sorry Błażej, i found this bug "[BUG] creating records #1739" is a CRITICAL BUG for a "stable" version!!!!

You cannot SELECT or ADD an entry from a related tab! You can test this at https://test.yetiforce.com.

In my opinion (with over 15 years experience in Softwaredevelopment and as a CRM-Consultant), normally a version that named "stable" should be stable and must be fixed to a stable version. This cannot wait to the next stable release (with new features and new bugs) .

[waw555]

I fully support the users of the system! The stable version should be stable - it is an indisputable fact!

I saw your system at the stage of version 1.0 really liked the functionality and activity of developers, and to version 2.1 I was hoping that there will be a stable version, with which I can work, but alas, still a lot of mistakes, so at this point, I must decrease its activity in this project and the introduction of the company to do other system crm, which is very sad for me.

Wait bug fixes from version to version for a month - I can not.

It is necessary to introduce a system of auto-update or patch. Why can not I run the auto-update mechanism? Files can be compared to the amounts and offer the administrator to replace them or to change automatically. How often are changes in the database DATA? They also can be made, if they do not change the user data. You can offer to the administrator to see the changes and decide to update the database or not, made before this backup.

In Module backup, restore function is needed in order not to have to handle all the digging, and picked back up and restore.

I'll wait for a stable version !!!

[bpabiszczak]

Huge companies like Microsoft, despite 400 testing procedures, release faulty software that might cause the operational system to stop working. Errors reported by the users are not fixed for years, and this is a great example of an error like that: http://wccftech.com/redirect-to-smb-windows-security-bug/. There are hundreds of such issues, they apply to every company, regardless whether it hires 1 or 10.000 employees, the only thing that changes is the scale of their problems.

SkavenKF – it's not exceptional that you found an error in a system that was released. We reported dozens of issues related to the stable versions to Vtiger, some of them haven't been fixed by now, yet they still release new stable versions. When we published YetiForce 2.1 there were no reported important issues, and the test version had been available for several weeks, we fixed what we could find. The fact that the issue you reported still existed in the system wasn't caused by us fixing the issues slowly, but by our testers' and community testers' insufficient work. If you don't report an issue it won't be fixed. It results from many reasons, but the most important one is that most of the companies use 10 – 20% of the system capacity, so not everyone sees the error where we see it.

waw555 - you know exactly how it works, you can accomplish more than the others only by working hard. I don't know what errors you're talking about, but they haven't been reported, and since they haven't been reported we might probably skip them. If you report them, we will fix them within 2-4 work days. It is mostly up to the community how quickly we can find ourselves in a situation where everyone is satisfied with the system functioning.

zebrahosting & waw555 – a few days after YetiForce 2.1 was released you reported some issues and asked us to fix them as soon as possible. We prepared 2.1.39 update package for you [it's in the 2.2 folder because this package will change into the final 2.2 version in 3 weeks] – the package has a developer status, and was shared with the interested users in order to check whether it solves their problems- regardless of what the name of the folder it was placed in [because I think you are concerned about that] the package updates the system to v2.1.39 so the numeration logic was preserved according to this article : https://yetiforce.com/en/administrator-documentation/instalation/138-yetiforce-number-system.html. Just like in Windows, my system version is 10.0.10240 right now. So my question is- what is your deal with the numeration, because I can't quite get it? It seems like you concentrate on less important matters; remember it's just a number, nothing more.

waw555 – currently you don't have to wait for weeks for fixes, when you report a fix we give you a link to a revision when we close it, you can apply the fix manually. Additionally, we release update packages weekly [developer version], they include all fixes up to the day of publication; in case it turns out there are some errors in it and you report them, then the next day you'd get a fixed package. As you see, it's up to you and the others how stable YetiForce will eventually be.

waw555 – at the moment we don't plan to deploy the auto update mechanism [and we probably never will]. I'd think about that functionality if it took more than 30 seconds to update it manually... so why should we automatize it? Another thing is that auto updates could cause a variety of problems and we would be the ones responsible for them. I don't want to be responsible for something I can't control. The third and most important matter is that no large company uses anything like auto updates in their key systems [even on the Windows server no large company uses auto update]. In addition to that, most companies disabled the access to the Internet from their CRM server in firewall. The next problem you can't see is that YetiForce is based on Vtiger, and almost everything in there is placed in the database, so we update the database every day; until the configuration and the users data are separated every update will be problematic.

waw555 - If you want to be able to restore the system from backup then you should open a new issue - one issue per one problem.

waw555 – I respect your decision about the choice of CRM. Everybody understands stability in a different way. There are some customers who open the calendar in Vtiger and say that it is impossible to work with. [it takes minutes to load the calendar tab when there are many users], then they open the mail client and it turns out it doesn't even resemble a mail client, they set picklist filters and they don't work either... For someone else Vtiger is a perfect solution, somebody else ignores both of these systems and deploys a completely different one. This is called freedom of choice. We put a lot of energy to make out product stable. At the moment the following mistakes are to be fixed: https://github.com/YetiForceCompany/YetiForceCRM/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22YetiForce+2.2+GA%22+label%3Abug and I can't see any critical errors in here, so for me the system is stable, because the extent to which we, our clients, and the community use it shows that there are no critical errors in the key functionalities – if there were any, we would fix them.

[SkavenKF]

moved from #1656:

I have also the problem that i would update a vt5.4 productiv system to yf, since version 1.0. But every "stable" yf release have bugs, process changes (ex. lost of contact) and a lot of changes.

I think we need a update/bugfixing strategie for the stable version, similar to the following. Stable Version is 2.0.n, next 2.2.n, next 2.4.n and so on Master/Developer 2.1.n, next 2.3.n, next, 2.5.n and so on Update from 2.0 to 2.2, 2.2 to 2.4, etc. (for all patches x.x.n)

[SkavenKF]

First, if found it very good, that we have more discussions and more infos from yf team +1 :-)

@bpabiszczak: Sorry, what you write is wrong. I HAVE tested yf every week, minimum with one master version, and this bug wasn't in this versions. In my opinion the problem is, that are many (untested?) commits in the days before you release the stable version. And not all of this commits are bugfixes. I think, when you release a stable, we need a testphase over 1-2 weeks with only bugfixes: ex. first a release candidate and after 2 weeks a stable (+ support for critical bugfixes and update).

[bpabiszczak]

@SkavenKF

Your suggestion unfortunately isn't better and it doesn't solve anything. I don't think you see what there already is. You can test the new version in real time !!! You don't have to wait for 1 – 2 weeks before the release. What's more, you can test how every single change affects the system's stability. Everyone can monitor the developer and master versions, and check the changes here: https://gitmaster.yetiforce.com/ and https://gitdeveloper.yetiforce.com/. Are you sure you're utilizing all the tools available to you ? I don't think so

You're talking about some errors that you see, but you don't report any issues here: https://github.com/YetiForceCompany/YetiForceCRM/issues. You're with us from the very beginning, and I can only see 8 issues reported by you, most of them are low priority. So my question is – how should we know what to fix if you didn't report it? Some of these errors we notice on our own, some will remain because nobody reports them. You have an actual influence on how stable YetiForce is.