Please, Please, Please finalize a version of 1.3

[Hanz]

I have been coming along with trunk since April 2015…It has grown to be an awesome package for imaging that destroys SCCM, hands down, in speed. Unfortunately we are now on revision 6303, with numerous NEW issues arising with just about every update. I have been very fortunate to be granted permission to run a “beta/trunk” version within our environment, which I feel hopefully has helped Tom and the other developers on the team with situations just not possible to duplicate in a virtual realm. Single server with multiple storage nodes, seperated by routers and vlans.

I don’t understand, with FOG 2.0 supposedly in the works, why we don’t have a final stable version of Fog 1.3.0 available yet. As of 3 months ago it was decided that no more feature requests would be accepted in order to finalize; however, as I mentioned before, it seems that multiple things are being changed, even if already working correctly.

This is becoming increasingly frustrating when I update to fix one problem, only to be confronted with two or three other things broken. So please, with all due respect, let’s finish “THIS” version as a stable one, and then begin working on the next version seperate.

I’d like to finish by thanking the whole development team, especially Tom Elliott, as I’ve bothered him plenty with just about every issue, for creating this wonderful software.

[Wayne Workman]

IMO it’s really close.

But, let’s not make snap decisions? I mean - once a release candidate is chosen - we need to let it go for some time - make an announcement that there is a release candidate - and recommend that everyone currently using FOG Trunk update to the RC. Then, we wait… and wait a little more. Maybe a month or two - to make sure there are no issues.

But I do agree - the feature requests can stop - so long as we are positive that Surfaces and other tablets and newer laptops work great - and if there are any issues - that FOG provides reasonable ability to solve or work around them (exit types, boot files, HDD, kernels, etc).

I myself still need to do extensive testing with Windows 10 UEFI/GPT - we are going to do a massive windows 10 deployment this coming summer and I need to ensure all our hardware is good to go.

There’s also been some questions raised lately about speed - I’ll admit I’ve not really paid a lot of attention to several threads recently because I’ve been focusing on something at work, but there are still kinks to work out - and we need to go through a reasonable RC phase where we get the word out about RC and have everyone get on it.

[Hanz]

@Wayne-Workman I think it’s very close indeed, and do realize there are a lot of things that needed to be changed in order to make gpt/uefi/windows 10 work properly. I’m not really complaining as I’ve used many different coding languages, except php, and completely understand the complexities with trying to perfect a program, but we should have a better idea than “hopefully sometime”. It’s just a little discouraging sometimes.