Is there a policy for stable, longterm releases with backported bug fixes?

May 28 at 10:25 AM
Hello,

Does the PTVS team have a policy for stable, longterm releases with backported bug fixes? For example, if there's a known bug that gets fixed in the latest source repository head version, will that fix always be applied to 2.0 or something? If so, how do we know which versions have what support lifetimes? If not, are there any short-term plans to adopt such a policy, or failing that - how does the PTVS team see users getting fixes without always using the latest "bleeding edge" version?

Thanks and regards,
Tony
Coordinator
May 30 at 10:06 PM
hi tony,

there hasn't been a stated policy so far - not because we don't to write it down, but primarily because we're trying to learn what it should be based on customer requests.

clearly back porting bug fixes is costly (testing, internal processes, etc.), but nice for customers that are on previous versions of PTVS. if we had more resources, we would definitely put out dot releases. however we don't, so calories are primarily spent on bug fixes / features in the latest version (which so far have supported 2010, 2012, 2013). note that there is no PSS for PTVS - the devs provide direct support.

another factor to consider is that based on download data (see DL stats page), the majority of our users are on the latest stable version (2013 in this case). if the data was more titled towards older PTVS or VS releases, we would have made this a priority earlier.

if there are important security, data loss, etc. bugs - well those are different and we'd definitely consider them if the user absolutely cannot upgrade to the later PTVS versions. another fact of life (sadly) is who the customer is. if i'm a hobby dev asking for a backport for a minor issue i might not get it, but if 2000 devs from Pfeizer ask (esp if they're paying customers :)), our mgmt might have a different view.

last but not least, we have detailed build instructions & many cases fixes can be backported by devs themselves if push comes to shove.

sorry about the hand-way reply, but those are the parameters. we'll post something after an internal discussion.

thx,

s
Jun 20 at 12:09 PM
Thanks for the informative reply, and sorry for this rather slow acknowledgement. My team/company's demoing a PTVS-based environment, so we may be coming back to you on this medium term, and appreciate the background and options we might explore later....

Thanks and regards,
Tony