Release Notes

Skip to end of metadata
Go to start of metadata

The Release Notes are our chance to tell you about all the great fixes and improvements we have added to the system. They are organized by version, then by newest to oldest. 

 

 

OPS-COM Web Application

OPS-COM for Android 

 

Labels (1)

Comments  (9)

9 Comments

  1. Robin Mulloy

    Shannon Jones

    Some thoughts on this page and release notes in general.

    If we are directing clients here then I would like to standardize on the titles.  I think if the date is a prefix then we do not also need to spell it out.  

    Then we could standardize on:  [Web | Android | General] [Maintenance | Major | Version #] 

    The word "Release" (and "notes") is redundant since the parent branch is "Release Notes"

    So the list might now be...

    06/27/17 - Web Maintenance
    05/18/17 - Android v5.24.170609
    05/05/17 - Web Maintenance
    08/07/14 - Web Maintenance       <---  2014 ??  (smile)
    09/28/17 - Web Major

    • perhaps we should version stamp releases like I have done with Android.  eg. Major.Minor.date_of_release
      • 'Major' changes only when there is a major update
      • 'Minor' changes every time there is a new release unless minor hot fix
      • 'date_of_release' represents the date that it was made available to production
    • for a nicer date display, it could be:  2017-06-19   (which is also good for sorting)
      • I think the most current should be at the top; right now it is a bit of a mix up

    Within the document, I would like the Table of Contents to be used as the first element on the page.  That macro will list the items then that have a Heading font attribute.  So as an example the September release would actually have a 9 bullet TOC that would link to the specific items.  I think that clients may only be interested in one or two things and aren't likely to read the whole release note.  The way it is now, it is not easy to find the general details about what was changed.

    I don't think that would add a lot of overhead to the production since it is just a 3-4 word header then the explanation as it exists now.  (and I would suggest to keep the bullet short and to the point)

    I am open to your thoughts and comments.

  2. Shannon Jones

    Robin Mulloy I like these suggestions. I am trying to implement them and see if I run into anything that raises questions for me. I really like the idea of stamping the releases with a version. I will look at that further as well. Take a look at the 09/28/17 page. There is a toc there now. Is this what you have in mind?

    1. Robin Mulloy

      Shannon Jones   YES!!  awesome!  (smile) 

      It makes the document so much more easier to review, and as we get more of these it will make it easier for us to quickly scan through them as well (and if needed).

      PS>  As with all my suggestions know that I am happy to help if necessary..

    2. Robin Mulloy

      I see you renamed the pages as well, great.  As a suggestion, the year should be first then the month. 

      That way items will be grouped appropriately, otherwise every January item will all appear together as an example.

      consider the following...

      currentsuggested

      01/12/16
      01/23/16
      01/24/17
      02/04/16
      02/06/17
      02/21/16

      17-02-06
      17-01-24
      16-02-21
      16-02-04
      16-01-23
      16-01-12

  3. Shannon Jones

    Robin Mulloy So for Versioning, I spoke with Paul and he doesn't use it for the code but for the purposes of the release notes how does this sound:

    We have to start somewhere so OPS-COM Major version - 4

    Minor is the number of the month and it will go up with each Minor release - So the first release notes are from May so - 5

    Date of Release - yymmdd 

    So the 05/05/17 release would now be 4.5.170505

    06/27/17 release would be 4.6.170627

    https://wiki.tomahawk.ca/x/cANCAg shows the versioning for the latest release.

    Make sense?

    1. Robin Mulloy

      Shannon Jones   Sure sounds good.  I can update my versioning to match with the Android software..  For me the minor version just continued to go up and only reset wwhen the major version changed.

      Hmmm... as I typed that, what about releases in December and January..  4.1.???? as an example could span a year if there is no major update.  Maybe the version would become 13 instead of going back to 1  ?  ie.  4.1.xxx  – 4.12.xxx   4.13.xxx    

      I get that the year is part of the date stamp, but we'd end up with intermixing of releases on a listing if "4.1" were re-used as an example.

  4. Shannon Jones

    For future consideration - An improved way of presenting our release notes - https://blog.axosoft.com/gitkraken-v3-1/

  5. Shannon Jones

    Paul and I have decided to use v6 for the Laravel code

  6. Shannon Jones

    Release notes that contain internal fixes only can be viewed on the private side at - https://wiki.tomahawk.ca/x/ggBt

Attachments  (0)

Add Attachment
  File Modified
No files shared here yet.