Despite the vernacular, Group versioning is really nothing more than versioning by date. Most, if not all, Azure services version this way. You can choose whether you want to version by number or date - the two most common formats. Versioning by Group (e.g. date) is convenient for services. You know exactly when things were released. It can be difficult to track when a numeric version was deployed over time. Whether you map the group to some internal value is up to you, but I would claim it doesn't bring you anything but complexity and confusion. If you use a date for your version number, embrace it through and through.
The guidelines somewhat imply that you can have varying minor versions mapping to a single group (e.g. date); that could be dangerous. It's generally assumed that a minor version is backward compatible; however, a service should never assume that this is true. A service has no control over a client and their ability to handle even additive content (e.g. tolerant reader). The only type of versioning behind a group that should ever be done is patching, which has no visible wire protocol differences. You'll have to decide if it's worth mapping patch versions to groups/dates internally.
Whether you choose to version by number, date, or even both, is up to you. ASP.NET API Versioning is one such realization of these guidelines. It also includes support for a status (ex: Beta), which no longer appears in the formal REST guidelines. The wiki contains in-depth details.
I hope that helps.