When going to https://peppermintos.com/guide/downloading/ there is no description of the version is it 10 or 11. Also the version of Peppermint is not displayed in the OS itself. If a user does a neofetch no version is displayed so the running version cannot be determined combined with the download page has no version description it is a problem in determining what your running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Verson 10 has been Deprecated and is no longer avialable for download from the site.
With said.... we only deal with 64 and 32 builds no spcific versions.... you decide if you want a Debian base or a Devuan base
In terminal if you run neofetch look at the OS section if you see this Peppermint OS x86_64 that means you are running he 64bit build of Peppermint.
So...there is no versions to keep up with or to figure out if you have the most recent things install... when you run the Update Manager in the Pephub or schedule it to update your system will be updated. The Pep Tools is our custom tool sets that we maintain and the System Updates are the normal debian/devuan updates.
We do use the DevOps culture and the CI/CD pipelines for our development process it is a very common practice used today. In many cases for many teams that has turned into DevSecOps
DevOps automation and CI/CD are major components of many different application development cultures and they greatly enhance this process, giving advantages to both the software development team members and the community. Many organizations implement these processes today... Let’s take a closer look at the advantages of DevOps automation and CI/CD.
Helps catch problems
CI/CD pipelines enable the integration of smaller clusters of code, which makes it easier to deal with the possible problems that always occur in code. These smaller parts can be tested right after they are merged into the code repository. We in essence can write and reuse unit tests, This allows the team to catch and work on an issue right away. Finally, using CI/CD pipelines helps with identification of (bugs). That’s a great solution for huge teams that's why large companies use CI/CD, but it is also a great tool-set for those of us who volunteer and work remotely which is all of the Peppermint team around the world, when the communication between the team members can be delayed at times.
Faster release rates
If issues are caught earlier, they are fixed faster. It ensures faster release times on condition that the developers continuously create the code which we do for specific tools. In other words, CI/CD pipelines provide for the consistent code integration and deployment, getting the code ready for release. With the potential to speed up the development process, via the automated delivery pipelines, We do this using our own CD pipeline and working with Woodpecker CI so that we can run our pipelines in Docker Containers.
Automated delivery pipelines as I mentioned above we built this already, gives fewer errors and when they do occur, we can find them quickly. This means that the developer and community contributors don't have to make so many changes in the code so that they can focus on developing and innovation.
Continuous integration
This is the method that lets us automate integration of any changes in code from different developers of the team and community. In essence, continuous integration ensures the code quality and includes code analysis, compilation, code packaging, and unit testing. WoodPecker helps us containerize our pipelines so that we can run the code and ensure it of good quality before it reaches the git repos.
Continuous delivery
This approach provides us with frequent and fast production release. Nobody is manually uploading production code to the production CodeBerg repos it happens after the code has been tested.......... after it is committed we use continuous delivery so that we can release at any time. That is why there are no versions or point releases for peppermint that information is stored in the git repo history.... Continuous delivery, lets us set the release frequency, for example, we can do daily or weekly on any of the code base.
Continuous delivery enables quick releases. See...... the automation is the core principle of continuous delivery and it helps to effectively automate releases. We have built our own tool set to do this. Even down to the ISO deployment. We release when we want as we need to...
So,... Yes we have migrated from a single waterfall development practice to a DevOps CI/CD process and culture
We are based on Debian / Devuan
Yes we are and no we do not change any of that code at all. apt update / upgrade will do what they always do, no more no less
That is why you will not see point release or versions with Peppermint,
If you want to know if you are running Debian or Devuan builds in terminal run sudo apt info systemd to see the systemd version or /sbin/init --version/sbin/init --version to see your sysv version
I hope this helps you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How is a user to know what version of peppermint they are running. You said version 10 has been deprecated when did this occur? When did 11 become the latest ? If Peppermint updates to the latest how can a user make that determination?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In terminal if you run neofetch look at the OS section if you see this Peppermint OS x86_64 or that Peppermint OS x86_32 that is a release in 2022. Otherwise it will show PeppermintOS 10
When did 11 become the latest ? There is no PeppermintOS 11 it is just PeppermintOS and that came about in 2022
If Peppermint updates to the latest how can a user make that determination?
Updates for the Peppermint Custom Tool features is continuous, so if you want to see what is the latest features/changes released they are listed in the build log here: https://sourceforge.net/projects/peppermintos/files/BuildDate.txt/download
Yes we are based on Debian (11) and Devuan (4) and any future versions they come out with
Any updated and point releases they do will make its way into PeppermintOS automatically
If you want to see where you stand there you can run in terminal lsb_release -a
You will see something like this Distributor ID: Peppermint - this is us Description: Peppermint OS - this is us Release: 11.4 - this is the Debian/Devuan Version Codename: bullseye - this is the name
So.... according to the above I am running PeppermintOS Based on Debian 11.4 Bullseye in this example
Other than that I am not really sure what else to say...Its just PeppermintOS that we constantly update as needed...... we log the changes and we base on Debian and Devuan and their point releases.
Hope this helps
Last edit: Peppermint OS 2022-08-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. The reason I am concerned is the ISO file I downloaded in mid July 2022 was sha512 34a13d049f512f9461f557ec86f06a6e844086efdf5c0d0ae23dd7b0b3bccac949d4ce0f497e17873706eb704ed5e86d4120b2707733eb79dfbbe0df79ee685f
but the current download is a different sha512 hash is dfferent and I have the same values for lsb_release -a and I did not get any O.S. update notification just a few apps and OS commands like unzip etc.. What is the difference between the two sha512 versions ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi cam, the different sha512's are a result of the download iso's being upgraded occasionally. If one of the sha512's matches your results, then you're good to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the difference ? between sha512
34a13d049f512f9461f557ec86f06a6e844086efdf5c0d0ae23dd7b0b3bccac949d4ce0f497e17873706eb704ed5e86d4120b2707733eb79dfbbe0df79ee685f
and the current?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know that any of us keep track of them by their sha512sum hash .
You can open the checksum file with a test editor and read it .
There should be a Birth Date for when the file was created.
Internally in the ISO there are several paces where the exact timestamp for the creation time happened.
Once you know the date it was built it can be checked to see what you might expect to be new.
We do keep an updated file for (most ) changes directly affecting the build.
When going to https://peppermintos.com/guide/downloading/ there is no description of the version is it 10 or 11. Also the version of Peppermint is not displayed in the OS itself. If a user does a neofetch no version is displayed so the running version cannot be determined combined with the download page has no version description it is a problem in determining what your running.
Verson 10 has been Deprecated and is no longer avialable for download from the site.
With said.... we only deal with 64 and 32 builds no spcific versions.... you decide if you want a Debian base or a Devuan base
In terminal if you run neofetch look at the OS section if you see this Peppermint OS x86_64 that means you are running he 64bit build of Peppermint.
So...there is no versions to keep up with or to figure out if you have the most recent things install... when you run the Update Manager in the Pephub or schedule it to update your system will be updated. The Pep Tools is our custom tool sets that we maintain and the System Updates are the normal debian/devuan updates.
We do use the DevOps culture and the CI/CD pipelines for our development process it is a very common practice used today. In many cases for many teams that has turned into DevSecOps
DevOps automation and CI/CD are major components of many different application development cultures and they greatly enhance this process, giving advantages to both the software development team members and the community. Many organizations implement these processes today... Let’s take a closer look at the advantages of DevOps automation and CI/CD.
Helps catch problems
CI/CD pipelines enable the integration of smaller clusters of code, which makes it easier to deal with the possible problems that always occur in code. These smaller parts can be tested right after they are merged into the code repository. We in essence can write and reuse unit tests, This allows the team to catch and work on an issue right away. Finally, using CI/CD pipelines helps with identification of (bugs). That’s a great solution for huge teams that's why large companies use CI/CD, but it is also a great tool-set for those of us who volunteer and work remotely which is all of the Peppermint team around the world, when the communication between the team members can be delayed at times.
Faster release rates
If issues are caught earlier, they are fixed faster. It ensures faster release times on condition that the developers continuously create the code which we do for specific tools. In other words, CI/CD pipelines provide for the consistent code integration and deployment, getting the code ready for release. With the potential to speed up the development process, via the automated delivery pipelines, We do this using our own CD pipeline and working with Woodpecker CI so that we can run our pipelines in Docker Containers.
Automated delivery pipelines as I mentioned above we built this already, gives fewer errors and when they do occur, we can find them quickly. This means that the developer and community contributors don't have to make so many changes in the code so that they can focus on developing and innovation.
Continuous integration
This is the method that lets us automate integration of any changes in code from different developers of the team and community. In essence, continuous integration ensures the code quality and includes code analysis, compilation, code packaging, and unit testing. WoodPecker helps us containerize our pipelines so that we can run the code and ensure it of good quality before it reaches the git repos.
Continuous delivery
This approach provides us with frequent and fast production release. Nobody is manually uploading production code to the production CodeBerg repos it happens after the code has been tested.......... after it is committed we use continuous delivery so that we can release at any time. That is why there are no versions or point releases for peppermint that information is stored in the git repo history.... Continuous delivery, lets us set the release frequency, for example, we can do daily or weekly on any of the code base.
Continuous delivery enables quick releases. See...... the automation is the core principle of continuous delivery and it helps to effectively automate releases. We have built our own tool set to do this. Even down to the ISO deployment. We release when we want as we need to...
So,... Yes we have migrated from a single waterfall development practice to a DevOps CI/CD process and culture
We are based on Debian / Devuan
Yes we are and no we do not change any of that code at all. apt update / upgrade will do what they always do, no more no less
That is why you will not see point release or versions with Peppermint,
If you want to know if you are running Debian or Devuan builds in terminal run sudo apt info systemd to see the systemd version or /sbin/init --version/sbin/init --version to see your sysv version
I hope this helps you.
How is a user to know what version of peppermint they are running. You said version 10 has been deprecated when did this occur? When did 11 become the latest ? If Peppermint updates to the latest how can a user make that determination?
In terminal if you run neofetch look at the OS section if you see this Peppermint OS x86_64 or that Peppermint OS x86_32 that is a release in 2022. Otherwise it will show PeppermintOS 10
When did 11 become the latest ? There is no PeppermintOS 11 it is just PeppermintOS and that came about in 2022
If Peppermint updates to the latest how can a user make that determination?
Updates for the Peppermint Custom Tool features is continuous, so if you want to see what is the latest features/changes released they are listed in the build log here:
https://sourceforge.net/projects/peppermintos/files/BuildDate.txt/download
Yes we are based on Debian (11) and Devuan (4) and any future versions they come out with
Any updated and point releases they do will make its way into PeppermintOS automatically
If you want to see where you stand there you can run in terminal
lsb_release -a
You will see something like this
Distributor ID: Peppermint - this is us
Description: Peppermint OS - this is us
Release: 11.4 - this is the Debian/Devuan Version
Codename: bullseye - this is the name
So.... according to the above I am running PeppermintOS Based on Debian 11.4 Bullseye in this example
Other than that I am not really sure what else to say...Its just PeppermintOS that we constantly update as needed...... we log the changes and we base on Debian and Devuan and their point releases.
Hope this helps
Last edit: Peppermint OS 2022-08-08
Thanks. The reason I am concerned is the ISO file I downloaded in mid July 2022 was sha512 34a13d049f512f9461f557ec86f06a6e844086efdf5c0d0ae23dd7b0b3bccac949d4ce0f497e17873706eb704ed5e86d4120b2707733eb79dfbbe0df79ee685f
but the current download is a different sha512 hash is dfferent and I have the same values for lsb_release -a and I did not get any O.S. update notification just a few apps and OS commands like unzip etc.. What is the difference between the two sha512 versions ?
Hi cam, the different sha512's are a result of the download iso's being upgraded occasionally. If one of the sha512's matches your results, then you're good to go.
What is the difference ? between sha512
34a13d049f512f9461f557ec86f06a6e844086efdf5c0d0ae23dd7b0b3bccac949d4ce0f497e17873706eb704ed5e86d4120b2707733eb79dfbbe0df79ee685f
and the current?
I don't know that any of us keep track of them by their sha512sum hash .
You can open the checksum file with a test editor and read it .
There should be a Birth Date for when the file was created.
Internally in the ISO there are several paces where the exact timestamp for the creation time happened.
Once you know the date it was built it can be checked to see what you might expect to be new.
We do keep an updated file for (most ) changes directly affecting the build.
You can find that here.
https://sourceforge.net/projects/peppermintos/files/BuildDate.txt/download.