Please make sure to mark a response as an accepted answer once you are all set - it makes it helpful for others looking for an answer and prevents the 'unanswered' list from including things which have been resolved.

Thanks! 

w $system.Version.GetNumber() will get you just the version number string

Joel - the first paragraph says that eGit is installed with Atelier automatically but Nicole has confirmed that this is not the case.  Could you please edit the article and remove that statement?

Thanks!

Ben

Robert - thanks for posting, and it's great seeing that you're still doing awesome work in this space!

All the best,

Ben

FYI ... we will have several sessions covering this topic at the Global Summit - attend if you can, otherwise check out the material afterwards!

For internal application development within InterSystems we use a variety of approaches, but the most common is as follows:

1) We use an internally developed issue tracking system, but we plan to eventually migrate to JIRA

2) We use Perforce for all of our source control 

3) We have BASE, TEST and LIVE environments for every application, typically BASE and TEST being cloned from VM snapshots of LIVE.  In addition to the Shared BASE VM, for those applications which are undergoing the highest rate of change, developers will create a local copy of the application to do their development work.  Some apps have all changes being developed on Shared BASE and the changes are progressed (via our Change Control tool) to TEST and the LIVE.  For applications where developers use Private BASEs, they commit there and then push the changes to Shared BASE and then to TEST and LIVE.

Feel free to ask questions (here or at Global Summit)!

Thanks for asking.

Thanks Lexi!  That is covered in the last point of this article as well:  https://community.intersystems.com/post/writing-forward-compatible-json-...

John,

If you haven't already done so, please contact the WRC to let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers).

Thanks,

Ben

John - if you haven't already done so, please contact the WRC and let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers)

Jennifer - Angular 2 is not supported by Angular Material.  By picking Angular 1.x Chris was able to demonstrate the stack selection that we're using for many internal applications as well as what many of our large customers are using (REST+AngularJS 1.x + Angular Material).

Brendan - I think you are missing a ( in:

    do file.WriteLine(^Global1key))

Pravin - nice article, thank you.

You might want to add "... using Extended Global Reference" to your Title (to make it easier to find in a search) and include a link to the documentation on that:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=... 

Thanks for contributing :)

Kyle,

The macros are intended to prevent developers from having to refactor code at the same time as they perform an upgrade, as well as make it easier for application providers who have code running on a number of versions.

I've learned from experience that it is always best to have the fewest moving parts when possible when doing an upgrade so you can quickly find the cause of any issues that pop up.  Therefore, I always try to write forward compatible code and only after all of my systems for a given codebase have been upgraded and are stable do I start to introduce backwards incompatible changes.  These macros allow that very nicely.  In addition, using the macros means that you have more flexibility to upgrade without having to schedule a concurrent refactoring project (even if it is just a find and replace refactoring project :) ).

All that being said, the macros are not intended for long-term use with-in an application.  Once the 2016.1 > 2016.2 hurdle has been cleared then my recommendation would be to pull out the macros (find & replace) and stick with Caché's native JSON access going forward.  But that can then be a project that takes place post-upgrade, thus simplifying the upgrade and lowering risk.

Joe,

Better yet, follow the instructions and use the Macros available in the following article (the macros are in a linked Gist code snippet) and then you can write your code in a way that it will work on 2016.1 and also on future versions of Caché without having to rewrite your JSON logic:

https://community.intersystems.com/post/writing-forward-compatible-json-...

Hope that helps!

Ben