Release Early, Release Often

SRP Computer Solutions, Inc. is adopting the philosophy of release early, release often for many of our products. Follow us on Facebook or Twitter to get notified every time there’s a release.

Given that we are a small community, we have the luxury of quickly providing enhancements and fixes to our customers. Sadly, we’ve not taken full advantage of it. For too long, we’ve let a product languish for weeks in pre-release mode, not wanting to flood our customers with updates.

New Version Numbering

Our first step in correcting course is to change our version numbering schema. We used to use the semantic standard, which was Major.Minor.Patch.RC, where RC stands for Release Candidate. Thus, 2.0.1.1 would really be 2.0.1 RC1, which indicates the first pre-release build of 2.0.1. Once the 2.0.1 is deemed stable for release, it’s version becomes 2.0.1.0. The problem is that 2.0.1.0 ends up being newer and more tested than 2.0.1.11.

Our new version number system uses Major.Minor.Patch.Build. Thus, larger version numbers are always newer than smaller ones. Here’s how we plan to increment our version numbers.

Major

Major increments under the following conditions:

1. The product is not entirely backward compatible, i.e., there are breaking changes on the customer’s end. For example, moving from OI 9 to OI 10.
2. There are so many significant additions that it feels like a new product. For example, we moved to SRP Editor 3.0 after adding unit testing and code templates, which significantly altered the UI.
3. The underlying code base of the product was significantly refactored or entirely rewritten. For example, SRP Utilities didn’t offer many new features in 2.0, but it had been entirely rewritten so it could support 64-bit and OI 10.

Though we will manage expectations, customers should not be surprised if you need make changes in your own software to adopt a major version change.

Minor

Minor increments under the following conditions:

1. There are new features. A feature is anything that is an addition to the product rather than an update, such as new components, user interfaces, module, or APIs. For example, a new service module called SRP_Date would be a new feature of SRP Utilities.
2. There are a few significant updates or many small updates. An update is anything that adds to existing features. For example, a new service added to SRP_Date called “AddMinutes” would be an update, not a new feature.

Customers should expect new features when they see minor updates.

Patch

Patch increments under the following conditions:

1. There are bug fixes.
2. There are a few small updates.
3. The code was refactored, perhaps for performance gains or platform compatibility reasons.

In general, customers should expect that the higher the patch number, the more stable and vetted the Major.Minor version is.

Build

The Build number might differ from product to product. It might be a date or it might be a number, but larger numbers will always indicate new builds. It increments when there are no logical changes to the product, or we are providing builds for testing. An example would be when an RDK is accidentally shipped with a missing component and needs to be rebuilt. It’s not really a change or fix to the product, just a mistake in the build itself.

Moving Forward

As indicated in the introduction, we’ll be posting to Twitter and Facebook every time there is a release. Sometimes, we’ll post a blog article on the update, especially if it contains a new feature that warrants a deeper explanation. In all other cases, we’ll tweet out the list of changes and a link to the product page.

Recent Releases

Here are the products we’ve released in the past few weeks without having announced on our social platforms. This will catch you up.

SRP ActiveX Controls

4.1.10

• EditTable. Added ClickOption method

4.1.9

• DirectConnect. Fixed bug where OnMessage would sometimes crash

• Schedule. Updated net code to better isolate UI thread from networking thread

4.1.8

• ReportTable. Fixed bug where ColumnHeaderFont would not work for some themes

4.1.7

• Subclass. Fixed bug where subclassing MDICLIENT would crash in OI 10

SRP Editor

3.1.4

• Fixed bug where new or blank record would have an empty margin and produce an error when pressing enter.

3.1.3

• Updated IConv/OConv context menus to better recognize legitimate conversions
• Improved record loading/editing speeds, especially for large records
• Fixed bug where Favorited records would sometimes reopen in Forced Readonly mode
• Fixed bug where Open Record dialog would not highlight correct field when opened
• Fixed bug where License screens would sometimes appear when they shouldn’t

3.1.2

• Updated editor to automatically insert SRP PreCompiler if unpacking syntax is detected (and auto-insert is enabled)

3.1.1

• Added option to disable auto-insertion of SRP PreCompiler

SRP Utilities

2.1.6

• Fixed bug in SRP_Run_Command where output would not go into variable if it was too long