PDA

View Full Version : version number scheme



Stephen W. Meeley
14-Nov-2005, 12:47 PM
Mark,

I'm not sure what your concerns are here. We have our revision numbering
designed around our business model (the combination of incremental
improvements and subscriptions) and it's been a stable model for 4 or 5
years now.

For instance, when you purchase a license associated with a revision
(say 11 for example), you know that you would get anything that happens
in the 11.x line, regardless of the status of any subscription. If you
wanted to be sure you would get anything that happens outside of the
11.x line (like 12.x line) you would simply make sure you keep you
subscription active. It's not a ploy; it's a published methodology
that's been in place since 8.x.

We also make it quite clear that we change the major revision every year
and associate a major improvement set with each major revision. 11.x was
made up of wide-ranging usability improvements (from structs and arrays
to database connectivity). 10.x was Web Services and lots of tool
improvements. 9.x was where the Windows and Web environments came
together and compiling / debugging was vastly improved. Etc. We usually
try to bring out the big new features in the initial (.0) rev of a major
cycle, and further refine them in the secondary (.1) rev, but that's not
always the case (in 9.x, the .1 rev was where the new generation of Web
Application Server made it's debut).

We also published our clear intent to have two releases per year (a .0
and .1) when the 9.x project was happening. Again, there was no intent
to fly under the radar or be ploy-like - we told everyone exactly what
we were doing and why.

So under the subscription model, it really makes no difference what the
revision number is or isn't - you're covered. If there is some reason
you don't want to keep subscriptions active, you at least have a clear
view of what is available to you for any particular license (you could
use a .0 or a .1 revision of the release associated with the license).

Best regards,

-SWM-

PS. To further clarify, using your own example applied to our published
methodology, Visual DataFlex 30 is scheduled to be released in March
2024. Not that I don't love you folks, but I'm hoping I'm not personally
involved in its release ;-)

PPS. We might choose to skip from Visual DataFlex 12 right to Visual
DataFlex 14 in 2007...


-----Original Message-----
From: Mark Rutherford [mailto:mark@maunzelectronics.com]
Posted At: Monday, November 14, 2005 10:41 AM
Posted To: product-direction
Conversation: version number scheme
Subject: version number scheme

I think the version numbering needs a major rethink.
At the rate of VDF releases it wont be long before someone is running
VDF7 and someone is running VDF 30 or something.

I see talk of VDF 12, we just had 11, and we just had 10...

Can someone explain to me why there is a major version released when in
fact it would be fine with a minor release or service pack?

Or is this a marketing ploy?
This issue seems to slide under the radar.

Mark Rutherford
14-Nov-2005, 02:08 PM
Stephen,

I get the idea... but what are you going to do when you run out of
numbers? <BFG>

Dont mind me im just trying to tease you on a monday :D
Granted, maybee calling it a 'ploy' was not really what I meant to say,
but it just seems like under a subscription model its a great deal, but
what about people that buy x release, and there is a bug that gets fixed
in x release, and now your not entitled to said bugfix?

It just seems to me that not only do you run out of numbers eventually,
but you cut someone off from a fix.

What if ...

Developer xyz buys vdf 11, and there is a bug that say, causes your app
to crash when it encounters a certain string, and the fix for that bug
is put into vdf 12? (ok im making this up :D)


Does that guy get a fix on his vdf11 runtime or what?


Stephen Meeley wrote:
> Mark,
>
> I'm not sure what your concerns are here. We have our revision numbering
> designed around our business model (the combination of incremental
> improvements and subscriptions) and it's been a stable model for 4 or 5
> years now.
>
> For instance, when you purchase a license associated with a revision
> (say 11 for example), you know that you would get anything that happens
> in the 11.x line, regardless of the status of any subscription. If you
> wanted to be sure you would get anything that happens outside of the
> 11.x line (like 12.x line) you would simply make sure you keep you
> subscription active. It's not a ploy; it's a published methodology
> that's been in place since 8.x.
>
> We also make it quite clear that we change the major revision every year
> and associate a major improvement set with each major revision. 11.x was
> made up of wide-ranging usability improvements (from structs and arrays
> to database connectivity). 10.x was Web Services and lots of tool
> improvements. 9.x was where the Windows and Web environments came
> together and compiling / debugging was vastly improved. Etc. We usually
> try to bring out the big new features in the initial (.0) rev of a major
> cycle, and further refine them in the secondary (.1) rev, but that's not
> always the case (in 9.x, the .1 rev was where the new generation of Web
> Application Server made it's debut).
>
> We also published our clear intent to have two releases per year (a .0
> and .1) when the 9.x project was happening. Again, there was no intent
> to fly under the radar or be ploy-like - we told everyone exactly what
> we were doing and why.
>
> So under the subscription model, it really makes no difference what the
> revision number is or isn't - you're covered. If there is some reason
> you don't want to keep subscriptions active, you at least have a clear
> view of what is available to you for any particular license (you could
> use a .0 or a .1 revision of the release associated with the license).
>
> Best regards,
>
> -SWM-
>
> PS. To further clarify, using your own example applied to our published
> methodology, Visual DataFlex 30 is scheduled to be released in March
> 2024. Not that I don't love you folks, but I'm hoping I'm not personally
> involved in its release ;-)
>
> PPS. We might choose to skip from Visual DataFlex 12 right to Visual
> DataFlex 14 in 2007...
>
>
> -----Original Message-----
> From: Mark Rutherford [mailto:mark@maunzelectronics.com]
> Posted At: Monday, November 14, 2005 10:41 AM
> Posted To: product-direction
> Conversation: version number scheme
> Subject: version number scheme
>
> I think the version numbering needs a major rethink.
> At the rate of VDF releases it wont be long before someone is running
> VDF7 and someone is running VDF 30 or something.
>
> I see talk of VDF 12, we just had 11, and we just had 10...
>
> Can someone explain to me why there is a major version released when in
> fact it would be fine with a minor release or service pack?
>
> Or is this a marketing ploy?
> This issue seems to slide under the radar.
>

David Martinko
14-Nov-2005, 02:48 PM
If you buy a Ford Explorer and it is found that it has a design flaw where the vehicle rolls over easily in an accident... does that
mean you should be given a new Ford Explorer when the next model comes out?

--
David Martinko
Redeemed Software
248-535-7495
RedeemedSoftware(SHIFT+2)Hotmail(PERIOD)com
www.redeemedsoftware.com
www.redeemedhosting.com
"Mark Rutherford" <mark@maunzelectronics.com> wrote in message news:1Nn$e6U6FHA.3872@dacmail.dataaccess.com...
Stephen,

I get the idea... but what are you going to do when you run out of
numbers? <BFG>

Dont mind me im just trying to tease you on a monday :D
Granted, maybee calling it a 'ploy' was not really what I meant to say,
but it just seems like under a subscription model its a great deal, but
what about people that buy x release, and there is a bug that gets fixed
in x release, and now your not entitled to said bugfix?

It just seems to me that not only do you run out of numbers eventually,
but you cut someone off from a fix.

What if ...

Developer xyz buys vdf 11, and there is a bug that say, causes your app
to crash when it encounters a certain string, and the fix for that bug
is put into vdf 12? (ok im making this up :D)


Does that guy get a fix on his vdf11 runtime or what?


Stephen Meeley wrote:
> Mark,
>
> I'm not sure what your concerns are here. We have our revision numbering
> designed around our business model (the combination of incremental
> improvements and subscriptions) and it's been a stable model for 4 or 5
> years now.
>
> For instance, when you purchase a license associated with a revision
> (say 11 for example), you know that you would get anything that happens
> in the 11.x line, regardless of the status of any subscription. If you
> wanted to be sure you would get anything that happens outside of the
> 11.x line (like 12.x line) you would simply make sure you keep you
> subscription active. It's not a ploy; it's a published methodology
> that's been in place since 8.x.
>
> We also make it quite clear that we change the major revision every year
> and associate a major improvement set with each major revision. 11.x was
> made up of wide-ranging usability improvements (from structs and arrays
> to database connectivity). 10.x was Web Services and lots of tool
> improvements. 9.x was where the Windows and Web environments came
> together and compiling / debugging was vastly improved. Etc. We usually
> try to bring out the big new features in the initial (.0) rev of a major
> cycle, and further refine them in the secondary (.1) rev, but that's not
> always the case (in 9.x, the .1 rev was where the new generation of Web
> Application Server made it's debut).
>
> We also published our clear intent to have two releases per year (a .0
> and .1) when the 9.x project was happening. Again, there was no intent
> to fly under the radar or be ploy-like - we told everyone exactly what
> we were doing and why.
>
> So under the subscription model, it really makes no difference what the
> revision number is or isn't - you're covered. If there is some reason
> you don't want to keep subscriptions active, you at least have a clear
> view of what is available to you for any particular license (you could
> use a .0 or a .1 revision of the release associated with the license).
>
> Best regards,
>
> -SWM-
>
> PS. To further clarify, using your own example applied to our published
> methodology, Visual DataFlex 30 is scheduled to be released in March
> 2024. Not that I don't love you folks, but I'm hoping I'm not personally
> involved in its release ;-)
>
> PPS. We might choose to skip from Visual DataFlex 12 right to Visual
> DataFlex 14 in 2007...
>
>
> -----Original Message-----
> From: Mark Rutherford [mailto:mark@maunzelectronics.com]
> Posted At: Monday, November 14, 2005 10:41 AM
> Posted To: product-direction
> Conversation: version number scheme
> Subject: version number scheme
>
> I think the version numbering needs a major rethink.
> At the rate of VDF releases it wont be long before someone is running
> VDF7 and someone is running VDF 30 or something.
>
> I see talk of VDF 12, we just had 11, and we just had 10...
>
> Can someone explain to me why there is a major version released when in
> fact it would be fine with a minor release or service pack?
>
> Or is this a marketing ploy?
> This issue seems to slide under the radar.
>

Mark Rutherford
14-Nov-2005, 03:09 PM
David Martinko wrote:
> If you buy a Ford Explorer and it is found that it has a design flaw where the vehicle rolls over easily in an accident... does that
> mean you should be given a new Ford Explorer when the next model comes out?
>
No, they DO fix it, dont they?

Anders Öhrt
15-Nov-2005, 08:43 AM
> What if ...
>
> Developer xyz buys vdf 11, and there is a bug that say, causes your app to
> crash when it encounters a certain string, and the fix for that bug is put
> into vdf 12? (ok im making this up :D)
>
>
> Does that guy get a fix on his vdf11 runtime or what?

Valid question, and it's happened to us. VDF 10.1 (which we're running since
dec 04) has a bug in WinPrint that sometimes crashes our application. We
where told no fix would be presented and that this was fixed in VDF 11.0. We
tried upgrading to 11.0 and found another bug which was even worse. Now
we've soon had this bug for a whole year without a fix and we're hoping VDF
11.1 will save us.

This has bothered me some, since it feels like DAW's product lifetime
dropped to 6 month.

// Anders

Anders Öhrt
15-Nov-2005, 08:43 AM
> If you buy a Ford Explorer and it is found that it has a design flaw where
> the vehicle rolls over easily in an accident... does that
> mean you should be given a new Ford Explorer when the next model comes
> out?

Of course not, but it does mean Ford will recall your car and fix it, even
if a new model had already hit the market.

// Anders

Garret Mott
15-Nov-2005, 09:02 AM
PMJI - But I will anyway <g>

I think this issue is exacerbated by the installation/registration scheme
used by VDF.

Currently, upgrading a customer to a later version is many steps & I haven't
come up with a good automated way of doing it that I can trust. Admittedly,
this is probably due to my inexperience/lack of knowledge.

In fairness, I have to say that MS doesn't do it much better (except the big
one - that one can do a transparent install that doesn't require the
separate install of a runtime), but why should we always limit ourselves to
this comparison?

I know this has been brought up about a zillion times - but I'd really like
to see a different way of doing the install.

Updates? Do we want to get like the MS "patch of the day"? I guess when
there's a bug, I would... Otherwise, no. Besides - I'm thinking that the
resources required would be too much.

Maybe a 2 year cycle for major releases? 11.0 Spring 2005, 11.1 Fall, 11.2
Spring 2006, 11.3 Fall 2006, 12.0 Jan. 2007?

This was a fairly random collection of thoughts, but what the heck -

Garret


"Anders Öhrt" <Anders.Ohrt@capslock.se> wrote in message
news:Z9M7Cqe6FHA.2708@dacmail.dataaccess.com...
>
>> What if ...
>>
>> Developer xyz buys vdf 11, and there is a bug that say, causes your app
>> to crash when it encounters a certain string, and the fix for that bug is
>> put into vdf 12? (ok im making this up :D)
>>
>>
>> Does that guy get a fix on his vdf11 runtime or what?
>
> Valid question, and it's happened to us. VDF 10.1 (which we're running
> since dec 04) has a bug in WinPrint that sometimes crashes our
> application. We where told no fix would be presented and that this was
> fixed in VDF 11.0. We tried upgrading to 11.0 and found another bug which
> was even worse. Now we've soon had this bug for a whole year without a fix
> and we're hoping VDF 11.1 will save us.
>
> This has bothered me some, since it feels like DAW's product lifetime
> dropped to 6 month.
>
> // Anders
>

Jim Albright
16-Nov-2005, 11:41 AM
Most likely only if the flaw is likely to cause injury (e.g. seat belts, brakes, airbags).
Otherwise, it would not be a recall.

Jim
"Anders Öhrt" <Anders.Ohrt@capslock.se> wrote in message
news:qN75dqe6FHA.3872@dacmail.dataaccess.com...
>
>> If you buy a Ford Explorer and it is found that it has a design flaw where the vehicle rolls over
>> easily in an accident... does that
>> mean you should be given a new Ford Explorer when the next model comes out?
>
> Of course not, but it does mean Ford will recall your car and fix it, even if a new model had
> already hit the market.
>
> // Anders
>

Jørgen Münster
18-Nov-2005, 12:11 PM
I have done some testing this Friday afternoon and when reaching closing
time I concluded that DataFlex will not run out of version numbers for at
least some decades ;-)

To be serious: in the good old days, major releases were rare. Then suddenly
Oracle, Ingress, Informix and all the others (including DataFlex) began to
launch major releases very often. The users got the feeling that SystemX
version 3.0 was very old compared to SystemY version 4.0. I'm sure there is
a marketing issue hidden here.

Have a nice weekend
Jørgen Münster


"Mark Rutherford" <mark@maunzelectronics.com> skrev i en meddelelse
news:1Nn$e6U6FHA.3872@dacmail.dataaccess.com...
> Stephen,
>
> I get the idea... but what are you going to do when you run out of
> numbers? <BFG>
>
> Dont mind me im just trying to tease you on a monday :D
> Granted, maybee calling it a 'ploy' was not really what I meant to say,
> but it just seems like under a subscription model its a great deal, but
> what about people that buy x release, and there is a bug that gets fixed
> in x release, and now your not entitled to said bugfix?
>
> It just seems to me that not only do you run out of numbers eventually,
> but you cut someone off from a fix.
>
> What if ...
>
> Developer xyz buys vdf 11, and there is a bug that say, causes your app to
> crash when it encounters a certain string, and the fix for that bug is put
> into vdf 12? (ok im making this up :D)
>
>
> Does that guy get a fix on his vdf11 runtime or what?
>
>
> Stephen Meeley wrote:
>> Mark,
>>
>> I'm not sure what your concerns are here. We have our revision numbering
>> designed around our business model (the combination of incremental
>> improvements and subscriptions) and it's been a stable model for 4 or 5
>> years now.
>>
>> For instance, when you purchase a license associated with a revision
>> (say 11 for example), you know that you would get anything that happens
>> in the 11.x line, regardless of the status of any subscription. If you
>> wanted to be sure you would get anything that happens outside of the
>> 11.x line (like 12.x line) you would simply make sure you keep you
>> subscription active. It's not a ploy; it's a published methodology
>> that's been in place since 8.x.
>>
>> We also make it quite clear that we change the major revision every year
>> and associate a major improvement set with each major revision. 11.x was
>> made up of wide-ranging usability improvements (from structs and arrays
>> to database connectivity). 10.x was Web Services and lots of tool
>> improvements. 9.x was where the Windows and Web environments came
>> together and compiling / debugging was vastly improved. Etc. We usually
>> try to bring out the big new features in the initial (.0) rev of a major
>> cycle, and further refine them in the secondary (.1) rev, but that's not
>> always the case (in 9.x, the .1 rev was where the new generation of Web
>> Application Server made it's debut).
>>
>> We also published our clear intent to have two releases per year (a .0
>> and .1) when the 9.x project was happening. Again, there was no intent
>> to fly under the radar or be ploy-like - we told everyone exactly what
>> we were doing and why.
>>
>> So under the subscription model, it really makes no difference what the
>> revision number is or isn't - you're covered. If there is some reason
>> you don't want to keep subscriptions active, you at least have a clear
>> view of what is available to you for any particular license (you could
>> use a .0 or a .1 revision of the release associated with the license).
>>
>> Best regards,
>>
>> -SWM-
>>
>> PS. To further clarify, using your own example applied to our published
>> methodology, Visual DataFlex 30 is scheduled to be released in March
>> 2024. Not that I don't love you folks, but I'm hoping I'm not personally
>> involved in its release ;-)
>>
>> PPS. We might choose to skip from Visual DataFlex 12 right to Visual
>> DataFlex 14 in 2007...
>>
>>
>> -----Original Message-----
>> From: Mark Rutherford [mailto:mark@maunzelectronics.com] Posted At:
>> Monday, November 14, 2005 10:41 AM
>> Posted To: product-direction
>> Conversation: version number scheme
>> Subject: version number scheme
>>
>> I think the version numbering needs a major rethink.
>> At the rate of VDF releases it wont be long before someone is running
>> VDF7 and someone is running VDF 30 or something.
>>
>> I see talk of VDF 12, we just had 11, and we just had 10...
>>
>> Can someone explain to me why there is a major version released when in
>> fact it would be fine with a minor release or service pack?
>>
>> Or is this a marketing ploy?
>> This issue seems to slide under the radar.
>>