v1.0.0

Hi all

As I've been sharing these templates more and more online, it's become apparent that changes made to them no longer affect me.
Use cases vary as much as preferences. As such, some structure will be needed.

Moving forward, the Templates will have the structure as follows:

Templates>
....Documentation>
..........Templater Docs
...............Feature Docs
..........TemplateCore Docs
....Templater>
..........Features>
..........template1
..........template2
....TemplateCore

Functionality, Features and templates

The following can be taken as assumptions for the foreseeable future.

1. Templates will continue being the template folder and host all the code.
2. Templater will continue to be the default folder for the Templater plugin.
3. Templater will continue to be the most feature-rich templates due to the versatility of its parent plugin.
4. TemplateCore will now also be maintained as an alternative to the Templater Plugin to give additional functionality where possible and allow ObsidianCore Users (those who don't use plugins) the ability to benefit from these features.
5. The Templates>Templater>Features folder will contain templates for users to play around with and vote on. Each feature template file will demonstrate the ability of the technology and some potential use cases (e.g. pulling in the title of the file).The features may not be implemented into the actual templates but will act as a showcase for what is possible. Each feature will be given an ID and be documented separately from the templates documentation.
6. The Features folder will only be added to and not taken away from. This will ensure those users dependant on it will not need to adapt. Each test feature will be given an identifier and have a suitable link to the documentation.
7. All templates will assume the same structure of Periodic Notes

Calendar >
Files >
Notes >
Periodic Notes >
		1.Daily Notes >
		2.Weekly Notes > 
		3.Quaterly Notes >
		4.Monthly Notes >
		5.Yearly notes >

8. Task tracking on the Daily notes is a requirement for all. These values don't infringe on anything else and can be removed easily if it really bothers people. However, the structure in place will be harder to recreate than destroy.

Documentation

The documentation folder will hold the official documentation on how to use and setup:

1. Templates
2. Features
3. Plugins
   Templates Documentation will contain details on the usecases that the template aims to cover and how to edit them as needed.
   Each feature will have documentation on how to use it individually and be referenced in other documentation.
   Plugins will show the assumed config that is required to get things working out of the box.

Branches

Any features will occur in a feature branch first before being added to the main branches (currently work, main, and personal) The develop branch will be used to experiment and test before official releases.

There are currently 3 release branches

• Main
• Work
• Personal

All 3 contain the same features, Feature documentation and overall strategy, provided they have the same major version number.
v1.x.x

There is a development branch that pulls from the main branch called dev.

If a feature is developed (the ability to have a journal entry in the daily note and all journal entries displayed in the weekly note as an embed) This will first exist in a feature/journelEntryEmbeds branch that pulls from dev and only placed back into dev once stable.

dev and main will sync and a new minor release is made and then with personal and work
v1.1.x

In the current form every daily journal entry for all 7 days of the week are embedded into the weekly template.
However, in a work context, there are typically only 5 working days in a week.
It doesn't make sense to have all 7 by default.
There editing the weeklytemplate for the work branch makes sense as it only requires 5 days embedded.

Commit v.1.1-editType.x will be made on the work branch to denote that work branch is synced with all the features of v1.1.x in main but required a modification.

This detail will be added to the documentation and explained in the readme.

If a patch is added to main v1.1.1. the other branches will also have this patch added. so the branches will look as such:

main v1.1.1.
Dev v1.1.1
Personal v1.1.1
Work v1.1-5dayweek.1

Where this denotes that work uses a 5 day week.

As version 1.2.0 comes around, work will also have 1.2.0 in the name but this change in 1.1.x will be noted in the readme and in the documentation folder