Loupe Server has a basic assumption that different builds of your application will be identified by distinct application versions.  It also assumes that these versions are ordered using semantic version rules, namely that given a Major.Minor.Build.Revision it can sort first by Major, then Minor, then Build, then Revision to identify later versions from earlier versions. 

For example, Loupe will assume that if an error is recorded as fixed in version 3.5.5.1593 and then happens again in 3.5.5.1597 that indicates it's happening in a "later" version. 

Date Encoded Versions

Some teams decide to use a date code for a version, typically for internal software where there isn't any public awareness of version numbers.  If your team does this, ensure that you use a Year.Month.Day approach to ensure versions sort correctly.  For example, 2014.07.01 will sort correctly whereas 7.1.2014 will not (because a build released in December of 2010 would have the number 12.1.2010 which is considered earlier).

Loupe uses Release Types to understand the promotion model of your organization.  Each organization has some workflow that differentiates builds of software done by the development team for their own purpose from those that are deployed for use by others.  Typically there are multiple levels in between

• Internal software often has a progression like Development -> QA -> Certification -> Production
• Public software often has a progression like Internal -> Alpha -> Beta -> Release

It's possible that a single build may start off in one state and then be "promoted" to a higher state as it gets validated and proven.  As long as it's the same build in Loupe you would reflect that by changing the Release Type for the version in question.  Loupe leverages this information in several ways:

• Issue Overview automatically scans for the previous version and current version of each release type as well as the next version that could be promoted to that release type.  This creates an easy to use display for each promotion step in your organization.
• Notification Rules and Issue Management Rules can use Release Type to constrain the set of events they work with. For example you may want a notification every time a new problem shows up in Production but not in QA.
• Usage displays can filter by minimum Release Type letting you see just usage of released versions of your application.

When a new application version is discovered by Loupe it is assigned the lowest Release Type (Internal by default).

Much of Loupe Server is organized around presenting you with important events that you should triage - and determine if they're a software defect or not.  If they aren't, you can suppress them and not be bothered with them again.  If they are then open an Issue.  This creates the tracking record in Loupe to highlight what's known about each release, identify the specific defects you should put time into fixing, and track your improvements from release to release.

Issues are designed to add value to your defect tracking system.  Whether you're using an Excel spreadsheet, email folder, or large ALMS for tracking all defects in your software Issues will augment that information.  For example, you might open a defect for each issue and add a link to the Issue page in Loupe.  This way any developer looking at the defect can see your tracking information and notes along with the latest information from the field on the specific error, exception, and log information leading up to it.  This is why Loupe Issues have a lightweight workflow - just enough to complement a defect tracking system (and work in an environment where there isn't one).

Loupe automatically extracts user information from each log message, but this information is limited.  It's possible to specify additional information such as a full name, contact information, and organizational details.  For more information see Developer's Guide - Capturing Application Users.