Big, big changes in 4D release program

Walt Nelson (5/1/14 6:18PM)
Michael Larue (5/2/14 2:25AM)
Keisuke Miyako (5/2/14 2:59AM)
Keisuke Miyako (5/2/14 3:21AM)
Thomas Maul (5/2/14 10:25AM)
Tim Nevels (5/2/14 2:26PM)
Michael Larue (5/2/14 9:42PM)


Walt Nelson (5/1/14 6:18 PM)

On May 1, 2014, at 5:59 PM, Keisuke Miyako <Keisuke.Miyako@...
wrote:

color><param>00000,0000,DDEE/param>iif you are a partner, or under
maintenance, I would encourage you to try
out R releases while they are new.
which is the whole point, and report any problems, especially with the
new
features, right away.
/color>
Miyako,

For those of us with Customers on maintenance, this could be a real
problem if they are somehow encouraged to upgrade to the latest R
release.

This has happened to me in the past with some clients, and there was
great gnashing of teeth on their (and my) part when stable system
became, well, less stable.

This concept of Partners and Maintenance owners serving as a second
line of beta testers is bound to fail. And fail hard.

Thanks for listening...

Thanks,
Walt Nelson (Seattle)
New stuff coming!
www.foundationshell.com
walt@...

Michael Larue (5/2/14 2:25 AM)

Friday, May 2, 2014 at 1:39:33 AM

Just curious on how this is going to work for the unwashed masses not
part of the "club 4D" (that is, regular paying customers who purchase
4D, but aren't partners or on maintenance).

Obviously the new "release" program (ie, r2, r3, etc.) are going to
include new features, and you can't get them unless you're in the
club. OK.

According to the announcement,

color><param>00000,0000,DDEE/param>FFor customers without Maintenance,
4D will continue to provide minor bug fix releases as in the past. New
features can be accessed by purchasing an upgrade as soon the next
major release is available.
/color>

So, supposedly bug fixes will continue to be made on the "base"
version. (I'm a little worried about the term "minor bug fix"--does
that mean "major bug fixes" don't happen??? Hopefully this is just
semantics, and that bug fixes mean _all_ bugs will be fixed, not just
the minor ones.)

We're currently on 14.1, so at some point 4D will fix all the
outstanding bugs and release 14.2. Cool.

Next, 14r2 is released. New spiffy features. Cool. But, oh no! A bug
is found in one of the new features. Darn. How'd that happen? So
14r2.1 is released (I'm guessing this is the numbering scheme, but
someone from 4D can jump in and correct this).

But uh oh--now a bug is found in 14.2 (the "base" version), _after_
14r2.1 has been released.

Is 4D going to continue to support the "base" version, even after new
"r" versions are released?

According to the chart on the 4D page for new releases, looks like
_lots_ of them "r" versions are going to be done. Which, of course, is
great for keeping the product moving along, and releasing changes in
smaller batches so they can be beta-tested by the club and won't take
so long to get them fixed.

But I see a bit of a problem for maintaining the "base" code base. Are
they going to continue fixing the "base" version (ie, 14.2, 14.3,
etc.) _at the same time_ they're doing all these new release versions?

Or, for simplicity sake (and of course, doesn't hurt to force the
users on to the maintenance program, thus more $$$ for 4D), will the
"base" version eventually be abandoned (ie, no more bug fixes) while
engineering resources are dedicated to the "r" versions? And on top of
that, there's version 13 bugs, too. Wow, lots and lots of versions to
support. Maybe. Not?

So, here's the $64,000 question: will the "base" version continue to
get bug fixes for the life of the product, until version 16 is
released? (Version 16, assuming 4D continues the "2 version" support
policy it's had to date.) Or once 4D gets rolling on those "r"
versions, you can forget about fixes to the "base" version?

4D?

Cheers!

Michael Larue

--------------------

Date: Thu, 01 May 2014 14:59:28 -0700
From: Jack Des Bouillons <Jack.DesBouillons@...

I know this was announced at last year's Summit, but it's importance
slipped
right over my head.

Everyone needs to take a look at the link Thomas Maul has provided
below...

On 5/1/14 12:59 AM, "Thomas Maul" <Thomas.Maul@... wrote:

color><param>8826F,0000,8219/param>TThere is no news of when 64bit 4D
Server for Mac OS will be released.
/color><color><param>00000,0000,DDEE/param>TThere is:
http://www.4d.com/news/4d-v14-r2-continuous-delivery.html
/color>
I had always thought that MAJOR upgrades would always come with an
upgrade
from, say v14 to v15...but this is no longer true. ¬=A0I would call
64bit
4D
Server for Mac OS something VERY major, it it will happen long before
we see
v15!

Keisuke Miyako (5/2/14 2:59 AM)

color><param>00000,0000,DDEE/param>SSo, here's the $64,000 question:
/color>

so how much is the answer worth? :)

yes, 14.2, 14.3 etc will be maintained, with bug fixes, just the way
they
have always been,
you don?=A2?=82¨=E2&Ntilde;¢t need to subscribe for maintenance or
become a partner to
get
those updates,
they will continue even after R2, R3 etc. are released.

in the past, a minor update, which was free, contained both fixes and
new
features.

I talk about it in my blog here:

http://www.4d.com/jp/blog/about-14r2.html

for example,

2004.1

pointers to local variables
a new command SHOW ON DISK
the ability to receive BLOB in SOAP
plus 100+ fixes.

2004.2

a run button in the form editor
a new form event On After Edit
the option to regenerate forms in 4D Tools
OS X 10.4 support
plus 100+ fixes.

2004.3

a new type of log (the wonderful #34 debug log file)

2 new commands INTEGRATE LOG FILE and New log file

new internal format of 4D Write

Windows 2003 Server support
plus 100+ fixes.

2004.4

another new command SET ALLOWED METHODS
the ability to specify the data file path in application build
Right-to-left language support
plus 100+ fixes.

2004.5

yet another new command GET LISTBOX CELL POSITION
display of client IP address on the server admin window
Print form support of 4D plugin areas
plus 100+ fixes.

2004.6

Windows Vista support

2004.7

OS X 10.5 support

With the new delivery system, there will be a separation between the
major
reasons for an upgrade,
namely, new features, new platform support, and bug fixes.

There are several benefits to this:

new features will be evaluated while they are still new, which is
better
for the engineering to fix if a bug is found.

each release (R or the first release) will be insulated from new
features
added in subsequent releases.
(the code is actually branched, it is not just a matter of disabling a
feature, if that?=A2?=82¨=E2&Ntilde;¢s what you?=A2?=82¨=E2&Ntilde;¢
re asking)

you don?=A2?=82¨=E2&Ntilde;¢t have to wait years for a new feature to
arrive, along with
100
or so other new features.

you get regular fixes.

so I hope that answers your question.

if you are a partner, or under maintenance, I would encourage you to
try
out R releases while they are new.
which is the whole point, and report any problems, especially with the
new
features, right away.

if you intend to stay with the first release, again, start using it
while
it is still relatively new,
and report any problems you find with it right away.

don?=A2?=82¨=E2&Ntilde;¢t wait until a ?=A2?=82¨=C5&igrave;version
is mature?=A2?=82¨=C2&ugrave;,
because by that time the development would have shifted to working on
R4
or R5,
and though there will still be fixes for the first release,
it would have be better if those issues had been dealt with at a much
earlier point,
while there were fewer branches to maintain.

and it?=A2?=82¨=E2&Ntilde;¢s not just about fixes,
if you could make a case for a new feature, or an enhancement,
you may see them in an R release rather than a major upgrade.

miyako

On 2014/05/02 9:25, "Michael Larue" <larue@... wrote:

color><param>00000,0000,DDEE/param>SSo, here's the $64,000 question:
will the "base" version continue to get
bug fixes for the life of the product, until version 16 is released?
(Version 16, assuming 4D continues the "2 version" support policy it's
had to date.) Or once 4D gets rolling on those "r" versions, you can
forget about fixes to the "base" version?
/color>

Keisuke Miyako (5/2/14 3:21 AM)

obviously I don?=A2?=82¨=E2&Ntilde;¢t mean end-users should upgrade
to R themselves.
that?=A2?=82¨=E2&Ntilde;¢s
nonsense.

there is nothing to gain in an R if the developer had not implemented
something based on a new feature that is only available in R.

it?=A2?=82¨=E2&Ntilde;¢s not a fix.

for that you have the dot updates.

miyako

On 2014/05/02 10:18, "Walt Nelson" <walt.nelson@... wrote:

color><param>00000,0000,DDEE/param>FFor those of us with Customers on
maintenance, this could be a real
problem if they are somehow encouraged to upgrade to the latest R
release.
/color>

Thomas Maul (5/2/14 10:25 AM)

Bug fixes:

14.0, 14.1, 14.2, 14.3 and so on, will continue to be
delivered/developed
as we did in 13.0, 13.1, 13.2 or 12.0, 12.1, 12.2, et. Nothing changes.
The text ?=80&ucirc;minor bug fixes?=80&uacute; was wrong, stupid translation
error,
sorry for
that. It should have been ?=80&ucirc;bug fixes in minor versions?=80&uacute;,
where
minor = dot
version, like 14.1

color><param>00000,0000,DDEE/param>OOr someone who likes a feature in
R2, and also another feature in R3,
but which no longer includes the feature from R2.
/color>
This is not how it works?=80¶

In the past, we developed, let?=80&ocirc;s say just as example, 100
features
in one
big development cycle. A feature could be a tiny one, like a new option
for an existing command, or a very big one, as 4D Mobile.
Development department works some months on development - then the
whole
set goes to internal testing, then to partner testing (=beta), then
shipped.

In reality, not every feature needs 8-12 months for development, some
are
ready after some days - and then kept ?=80&ucirc;in the fridge?=80&uacute;
till final
shipment.

And this is the major change now. We don?=80&ocirc;t start to work on all
features
in parallel, but break the process down in chunks. We focus on some
features. Full focus on a small set for development - and then full
focus
for testing. We are convinced that this will increase quality, and I
believe the reasons are obvious.

Finished features are shipped - if you need them for your product or if
they help to increase your market -you can use them directly, not
needing
to wait.

In parallel we changed the way we handle big features. We split them
down
in many tiny features. This allows to start testing them in a
production
ready version.

4D Product line on 64 bit for OS X - that?=80&ocirc;s more than 20
features.
Quick
Report Engine needs to be rewritten. Plugin Support. Network layer.
Printing. And much more. After all, 64 bit means 100% carbon free.

We have internally a 4D Server 64 bit for OS X which is running, but
cannot print. Still we can test everything - except printing.

Splitting down in tiny features allows much more detailed and
controlled
testing - compared to a whole new product with many changes, where
testing
is difficult as you cannot use it yet for production or run big
applications/data size.

So - as soon a feature is fully developed, internal testers run manual
tests. Automatic tests, both unit tests as automatic tests with 4D
databases, runs during development. We do internal builds not only once
per night but already once every hour, with automatically test even in
between daily work, starting again every hour. As soon something is
committed back to code - tests start.
We plan to have a session to tell more about our changed development
process on 4D Summit..

As soon all tests - unit tests, automatic tests and manual tests - give
?=80&ouml;green?=80&ograve;, the feature is tagged to be released with the
next R
release
beta. Beta test is scheduled to be 8-10 weeks. If we realize during
this
very last step that a feature is not ready, either because it has bugs
not
discovered through our test plan - or as it happened with a feature in
R2,
customer response says that this feature is not complete, wrong
designed,
compatibility issue or similar, we remove it from R2 during beta.

We prefer to deliver a version with less features, before shipping a
feature not fully working.
The feature will be delayed for the next R release, in worst case
several
releases.

As soon a feature is released in a R release, it will normally not
removed, at least not in the following R release. It might happen that
features are removed, we removed Novel network support as well as
AppleTalk network. We have removed QuickDraw and QuickTime support, as
we
will remove Carbon support soon. But this has good reasons - and we
usually announce them years ahead.

After several R releases the version becomes the next major version.

For customers without maintenance contract nothing changes, they
upgrade
as before as a paid upgrade to the next release. The only difference:
you
have a better view what?=80&ocirc;s happening - and we strongly believe
that
we will
increase the quality drastically, having a v15.0 with a very strong
product quality.

color><param>00000,0000,DDEE/param>FFor one thing, this increases the
need to be at the Summit is San
Antonio.
I was thinking that with v15 being so far in the future, and v14
discussed
in-depth at the last Summit, what was 4D going to present...
/color>
While there would be much more in v14 still to show/explain - we have
already a long list for keynote ideas for San Antonio and a even longer
list for break out sessions.
It is not just 64 Bit for Mac or the new 4D Write. We have many strong
features to be delivered this year.

Best regards
Thomas Maul

Tim Nevels (5/2/14 2:26 PM)

On May 2, 2014, at 1:54 PM, Thomas Maul wrote:

color><param>00000,0000,DDEE/param>SSo - as soon a feature is fully
developed, internal testers run manual
tests. Automatic tests, both unit tests as automatic tests with 4D
databases, runs during development. We do internal builds not only once
per night but already once every hour, with automatically test even in
between daily work, starting again every hour. As soon something is
committed back to code - tests start.
We plan to have a session to tell more about our changed development
process on 4D Summit..
/color>
It is great to see how 4D has changed from many years ago and how its
development and internal testing systems work. This all sounds very,
very good. I will certainly attend the summit session on 4D's
development process. I love this kind of stuff. It builds tremendous
confidence in the 4D product line. It looks like very soon all
developers will be able to use and deploy x.0 releases of 4D instead
of the standard "wait for x.1 or x.2 before you deploy".

color><param>00000,0000,DDEE/param>44D Product line on 64 bit for OS X
- that's more than 20 features. Quick
Report Engine needs to be rewritten. Plugin Support. Network layer.
Printing. And much more. After all, 64 bit means 100% carbon free.

We have internally a 4D Server 64 bit for OS X which is running, but
cannot print. Still we can test everything - except printing.
/color>
More very, very good news. I have Mac OS X clients now that would love
to have 64bit Mac OS X 4D Server so they can have more than a 2300MB
data cache. Based on your new development and testing procedures, I am
now seriously considering deploying your very first v14 R release that
contains 64bit Mac OS X 4D Server later this year.

Thank Thomas for this post. I think it is the best iNUG post so far
this year!

Tim

Michael Larue (5/2/14 9:42 PM)

Friday, May 2, 2014 at 5:38:48 PM

Hi Thomas,

Again, thank you very much for your lengthy explanation! Do appreciate
you taking the time to respond.

I guess I'm still a little confused by the responses from both you and
Miyako; he says,

color><param>00000,0000,DDEE/param>[[Miyako] each release (R or the
first release) will be insulated from new features added in subsequent
releases (the code is actually branched, it is not just a matter of
disabling a feature, if that?=80&ocirc;s what you?=80&ocirc;re asking)
/color>
and you say in reply to my message,

color><param>8826F,0000,8219/param>[[Michael] Or someone who likes a
feature in R2, and also another feature in R3,
but which no longer includes the feature from R2.
/color>
color><param>00000,0000,DDEE/param>[[Thomas] This is not how it
works...
/color>
I guess this will become apparent as you start rolling out the "r"
releases; it sounds like you're taking a good approach to breaking
down the major changes into more manageable chunks that can be better
tested and deployed. (I know with my databases I definitely try to
avoid doing more than one major change per update, since it can drive
you crazy trying to sort out bugs with multiple major changes).

And I think this is good you're doing these on the "r" path of
releases, which again (to me) sounds like a "sandbox" area for beta
releases, but nothing that directly affects the "base" branch of 14.1,
14.2, etc. So those of us with clients that _only_ want to use
"official", QA'd versions of 4D, we can feel reasonably assured these
people will be supported during the lifecycle of the product, and not
left out in limbo while 4D turns it's engineering attention to the
shiny new features being developed.

<opinion> Honestly, for me, 4D is _so_ feature rich, I'm still
struggling to keep up with all the changes introduced in versions 11,
12, and 13! You guys move very quickly, which is great for keeping on
top of the new technologies, interfaces, etc. But my BIGGEST beef is
that with all these features, bugs sort of just get shunt aside (and
have been for as long as I've been using 4D). Obviously it's a less
glamorous task for the programmers--I mean, who gets the applause at
the Summit? The folks showing off the new stuff. The poor drones in
the back room fixing things, whips cracking over their heads--they
never get any recognition for their work, even though _for me_ it's
FAR more critical to my system what they do versus anything coming
from the new development team. I would happily trade one year of new
features in 4D just to have _every_ bug fixed and that everything
works exactly as the docs indicate. Yeah, I know every program has
bugs (Zarro Boogs), and that fixing all
of them is probably impossible--but again, for me this is far more
important than new features. Bug fixes are what I need TODAY; new
features can wait. In fact, why is 4D even looking at building new
features as long as there are bugs in the product? The priority should
be getting these fixed, QA'd, and the next dot release out the door as
quickly as possible before _any_ engineering efforts are diverted to
new features. </opinion>

Anyway, the new "r" path also, as you say, gives a great "preview" of
what's coming in 15, and hopefully means when 15 is released, version
15.0 will be a winner (not like the dog 14.0 is).

So I applaud your goals with the change; hopefully this will be a good
thing for QA. But please, make bug fixes the #1 priority, not new
features. Upgrading to version 14 has really been quite a painful
experience*, and I hope with this new process it can be avoided in the
future.

Cheers!

Michael Larue

*just one example to illustrate what I'm talking about. There's
currently a bug with dates so that the following command, used
anywhere on any platform (Mac or PC) on any computer:

String(Current date;Internal date long)

Gives the date as:

April 15,2014

Note the missing space after the comma.

OK, you say, no biggie, just code around it so you do something like:

Replace string(String(Current date;Internal date long));",";", ")

But... this is used in many, many different places in the database.

Further, I've got a whole 4D Write template system built where the
users can have _hundreds_ of business letters set up that uses this
function (actually, using the current date feature in 4D Write, which
has the same problem).

So now, the end users have to hassle with this. They can no longer
just select a letter from the template list and print it, but now have
to go into each one _prior_ to printing and fix this so it'll come out
properly. Or I have automatic functions that send out e-mails using 4D
Write letter templates, so the users don't even see this, but now they
have to go back and fix these as well.

Major clusterf... and everybody is hurt by this. Users are pissed at
me for the bug in 4D. Management is pissed the users have to do all
this extra work. Management is also pissed that the upgrade introduced
new bugs (tell me again why did we upgrade? it worked perfectly
before...). Clients get a bad impression with the sloppy letter
content. Etc., etc. (And how on Earth did this bug get in in the first
place? Why was someone messing around with this code, a function that
has been around since the dawn of time in 4D and never had an issue
before???)

Sure, you say, just grab one of the nightly build beta versions...
not.

Sure, you say, it'll be fixed on the next dot update... but when?
Meanwhile, they need this _yesterday_.

And then, someday in the future, when version 14.2 comes out (assuming
this gets fixed in that version), now they (and I) have to go back and
change all of these code patches. And if they miss one, then get get
even more crap on the output. (Sure, I could build a function such as
"GetMonthDayYear" and change the code there so that once the fix is
in, I only have to change it in one place--but the users needed a
quick patch immediately, not waiting for a new structure update, so it
was impossible to set up this way. And it was also not practical to
have 2 methods for fixing this, one for prior to the new structure and
another for afterwards.)

And this is just _one_ of the many bugs we've run into on the upgrade
to 14. Major headache all around.

(Just think if a similar error was that all math functions using "+"
gave a result one number bigger. Sure, just change your code so you
subtract one from the result. Yeah, right. I ain't got nuthin' to do
all day. And then what happens when the bug is fixed...?)

OK, hopefully this illustrates the major pain we suffer through when
really basic bugs like these get through QA (two released versions of
4D!), and then take a long time for 4D to fix. Meanwhile, all this
talk about shiny new features... well, forgive me if I simply can't
get excited about them just yet. Let me go take some more aspirin and
I'll let you know in a few months...

Reply to this message

Summary created 5/2/14 at 3:56PM by Intellex Corporation

Comments welcome at: feedback@intellexcorp.com