1. Home
  2. Support
  3. New Features Policy
Searching...

New Features Policy

This policy does not apply to bugs. See our bug fix policy to learn about our approach to bug fixing.

How we choose what to implement

There are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine user feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.

How to track when features are implemented

Technology products

We’re continuously improving and updating our technology services, including G.J. Software. To see the latest changes, take a look at the release notes on our knowledge base. Important changes are also documented in our updates blog.

When a new feature or improvement is scheduled, we’ll update the fixed version on the relevant Jira issue to indicate the earliest product version that will include the change. This update often happens close to the product release date.

Knowledge Management Service (KMS)

Changes to our KMS, which included the knowledge base and LMS modules, are not reflected in our release notes. Though we may at times include updates about these changes in email communications to the franchise network. Depending on the magnitude of the change we may publish a post on our updates blog.

Legacy technology services

We’re simplifying our offerings and sharpening our focus on our cloud products. This means we’ve discontinued new feature development for our legacy technologies including the Green House (GJG2010), Intranet, and Supervisor App.

We’ll still be offering bug fixes for some issues. For details, see our bug fix policy.

Product roadmaps

We try our best to publish a public roadmap for our technology services to let you know what’s coming soon and what we’re thinking about for future updates. However, we’re a small team and we can’t always guarantee that it is 100% up to date.

The knowledge base release notes blog may also contain information on upcoming changes.

We don’t provide specific release dates for upcoming changes.

Feature and improvement suggestions

We encourage you to suggest improvements and new features for our products. You can create feature suggestions, or vote, watch, and comment on existing suggestions, at TK.

We get a large number of suggestions and feature requests. Your comments and votes on suggestions help us understand what you’re passionate about and how you want our products to support you and your team. The most helpful information you can provide us when commenting on issues is how a particular suggestion would help you. If you describe your use case to us, and how the suggested change would benefit you and your team, it lets us gain a much deeper understanding of the need behind the suggestion.

Suggestions often have an impact on what we work on, even if we ultimately choose not to implement a suggestion exactly as it’s described. Our ultimate goal is to understand what you and all of our franchises need and to create products that meet those needs. Occasionally, that’ll mean implementing a suggestion as described, but it usually means working to understand the need behind the suggestion and how we can meet that need for as many users as possible.

While we endeavor to update and respond to popular suggestions, the volume we receive means there will often be occasions when we can’t provide an update or response. We don’t provide any compensation or credit for feature suggestions that we implement.

Release terminology

  • Platform Release (example: 5.0) contains significant or breaking changes. For example changes or removal of existing APIs, significant changes to the user experience, or removal of a major feature.
  • Feature Release (example: 4.6) can contain new features, changes to existing features, changes to supported platforms (such as databases, operating systems, Git versions), or removal of features.
  • Maintenance Release (example: 4.6.2) can contain bug fixes and stability and performance improvements. Depending on the nature of the fixes they may introduce minor changes to existing features, but do not include new features or high-risk changes, so they can be adopted quickly.

Platform and feature releases may have a staggered deployment where they are shipped to the US production environments one week before AU/NZ. Simple database changes may be deployed directly to production if no new builds are required.

Release schedule terminology

Changes must be deployed to the staging environment (STG) at least two weeks before deploying to the production environment (PROD). This is to allow for one full week of user acceptance testing (UAT) and to develop new documentation and training updates. We strive to communicate upcoming changes 2-4 weeks prior to the release date.