Developer Update posts occur every 2nd Monday (unless a wallet release has occurred that week) and document upcoming changes to the wallet and features to look for in upcoming releases. It serves as an easy method for the developers to showcase their efforts between wallet updates.
I aim to write these updates in a way that the average Gridcoin user can understand. The core development team approves and helps write these posts.
Wallet releases are much more straightforward: they document when a new wallet version has been released, the changelog from GitHub, and the links to the relevant downloads for various operating systems.
that seems a little excessive, really. it sounds to me like you're just announcing things every 2 weeks, regardless of if there are any changes or not.
@peppernrino I respect your view that this may be spam because it doesn't contain any new information for you but for people who are more distant from the development, these updates can be really useful.
With the development updates it is understandable to have some repetition because the implementation is happening in stages. Personally I prefer to see these updates and confirm something is happening instead of hearing nothing and wondering what the development team is doing.
Finally, on average these updates have one of the highest upvote numbers on #gridcoin, which I think supports my view as well.
Respectfully, many people in the community have told me 2 weeks was the optimal time to post these updates (I originally wanted to post them monthly). Many community members are quite happy with the updates in their current state.
I would assume that answer would be that releases have listed fixes patched or code updated and has been fully tested via testnet and is why we do not run the current release on testnet and are running a newer unreleased version such as we are running 3.7.11.2 in testnet and I think or would think that build has the above listed updates where a release is not until the updates are fully tested and an actual production release built after everything is proven stable and or working that was proposed for updates.
Developer Update posts occur every 2nd Monday (unless a wallet release has occurred that week) and document upcoming changes to the wallet and features to look for in upcoming releases. It serves as an easy method for the developers to showcase their efforts between wallet updates.
I aim to write these updates in a way that the average Gridcoin user can understand. The core development team approves and helps write these posts.
Wallet releases are much more straightforward: they document when a new wallet version has been released, the changelog from GitHub, and the links to the relevant downloads for various operating systems.
I like this approach @barton26.
To me the development updates are as important as the actual product releases due to the different nature of information.
In the development updates I can see what is coming and the progress being made on certain topics (e.g. the CBR implementation).
Keep up the good work.
that seems a little excessive, really. it sounds to me like you're just announcing things every 2 weeks, regardless of if there are any changes or not.
in my opinion, that's spam.
@peppernrino I respect your view that this may be spam because it doesn't contain any new information for you but for people who are more distant from the development, these updates can be really useful.
With the development updates it is understandable to have some repetition because the implementation is happening in stages. Personally I prefer to see these updates and confirm something is happening instead of hearing nothing and wondering what the development team is doing.
Finally, on average these updates have one of the highest upvote numbers on #gridcoin, which I think supports my view as well.
Respectfully, many people in the community have told me 2 weeks was the optimal time to post these updates (I originally wanted to post them monthly). Many community members are quite happy with the updates in their current state.
I would assume that answer would be that releases have listed fixes patched or code updated and has been fully tested via testnet and is why we do not run the current release on testnet and are running a newer unreleased version such as we are running 3.7.11.2 in testnet and I think or would think that build has the above listed updates where a release is not until the updates are fully tested and an actual production release built after everything is proven stable and or working that was proposed for updates.