@Andre601 We'll be good to resolve #49 after you update changelog.

I will test this branch in https://github.com/PuneetGopinath/activity-test now.

@abhijoshi2k See those results in https://github.com/PuneetGopinath/activity-test/actions/runs/866856864
They passed, so I think this pr is ready for review

@abhijoshi2k Is there something you want to still commit in the timezone-fix branch?

@abhijoshi2k Is there something you want to still commit in the timezone-fix branch?

Changelog is still left

@PuneetGopinath let us stop all the work on #53 till this pr is merged and all conflicts are resolved.

@abhijoshi2k Why do we have to release minor version can't we release a new major version, v1.3.0 of our release has not followed semantic version already, can I update the Changelog and the draft release?

@abhijoshi2k Why do we have to release minor version can't we release a new major version, v1.3.0 of our release has not followed semantic version already, can I update the Changelog and the draft release?

Yes, we can go for v2.0.0 in next release

That's not how semantic versioning works imo.
1.4.0 is perfectly fine...

How?

Semver says to use a new major version when there is a breaking change.

I dislike that we delete the old changelog.
This goes completely against the purpose of a ChangeLOG

No, we should reset it when a new major version is released, that's why in the old format, I added the older changelogs section but you removed it!!
EDIT: Many folks consider to remove it when a new minor version is released

@PuneetGopinath @Andre601 can we keep changelogs of old version in separate folder then?

@PuneetGopinath @Andre601 can we keep changelogs of old version in separate folder then?

Yes, we can keep them, anyway they are available in the v1.3.0 tag

The Pull request of @abhijoshi2k has been marked as Ready!

It can now be reviewed and/or merged by Maintainers.

This is an automated response created by a GitHub Action
Mentioning the bot won't have any effect!

At least do that and link to it in the current change log...
But whatever. I don't have anything to do here anymore, since you two took over my only purpose here. So do wtf you want Idc anymore.

There's no need to get angry @Andre601 .
Let's work as a team. I don't think getting angry and exiting is a solution here. Mistakes do happen. Let's be considerate. 😊

Just make a backup of the old (v1) changelog now... Maybe in a .github/archives folder and named CHANGELOG_v1.md
That's all I ask for now.

I hurried because, am going to sleep

I shall merge it after we clear everything with @Andre601 . I don't want to hurt a team member here. I shall also resolve all the conflicts. You can sleep.

Just make a backup of the old (v1) changelog now... Maybe in a .github/archives folder and named CHANGELOG_v1.md
That's all I ask for now.

@abhijoshi2k You can get the old change log from the old changelogs section, then copy the raw content and create a new file and paste the content.

At least do that and link to it in the current change log...
But whatever. I don't have anything to do here anymore, since you two took over my only purpose here. So do wtf you want Idc anymore.

Don't become angery 😆

I am.
I work more than enough with projects who use semantic versioning and now you come here and essentially piss on this.
I never in my life saw any project that jumps to a new major version for some feature changes. So far I only saw actual major changes happening on entire recodes of the code. Everything else at most caused a minor change.

The actual, true semantic versioning is major.minor.patch_build where major is for recodes/extreme code changes, minor for changes without backwards compatibility, patch for changes with backwards compatibility and build for bug fixes and similar.

See for example JDA

It's just annoying that I'm here for README and CHANGELOG changes, yet you two take this over now and I get the back seat and reviewer role...

@PuneetGopinath let's make sure this doesn't happen anymore.
@Andre601 I'm sorry that this happened.
Let's put it in past and start fresh.
I hope you understand.

@abhijoshi2k We have breaking changes and that should release a new major version

I merged a .github/changelogs/CHANGELOG_v1.md file into this branch now.

At least do that and link to it in the current change log...
But whatever. I don't have anything to do here anymore, since you two took over my only purpose here. So do wtf you want Idc anymore.

Don't become angery 😆

I am.
I work more than enough with projects who use semantic versioning and now you come here and essentially piss on this.
I never in my life saw any project that jumps to a new major version for some feature changes. So far I only saw actual major changes happening on entire recodes of the code. Everything else at most caused a minor change.

The actual, true semantic versioning is major.minor.patch_build where major is for recodes/extreme code changes, minor for changes without backwards compatibility, patch for changes with backwards compatibility and build for bug fixes and similar.

See for example JDA

It's just annoying that I'm here for README and CHANGELOG changes, yet you two take this over now and I get the back seat and reviewer role...

Hello @Andre601, @PuneetGopinath and all, I just wanted to provide my two cents since my original ticket spurred this discussion and I don't want to see people upset on great working being done already. Debating can be a good thing and even healthy as long as no one takes it personal, and with versioning, there are always a lot of opinions. With that said, I will just share this, https://semver.org/. These are very clear guidelines, and with regards to Minor version, it says MINOR version when you add functionality in a backwards compatible manner. The key here is minor is not for breaking changes, but backwards compatible ones such as new features, or perhaps supporting new breaking changes of existing features while still supporting the old way marked as deprecated.

Keeping in mind the above, I think, at least in part, that some of the confusion is coming from releasing maybe too few breaking changes as a new version. For example, 1 breaking change causing the major version to update each time, which feels wrong as opposed to maybe 10. The discussion above seems to hover around both of these concepts. I won't say what I think is best, but I did just want to share some info in the hopes it helps work things out easier.

Thanks again everyone for your time and involvement in this.

Hello @StevenJDH ,
Thanks for the valuable information provided by you. We will surely go through it and take proper steps.
I hope that issue you faced regarding DST has been resolved.
Also, I wish to let you know that if you are using the main branch for your workflow, please note that the file structure is going to be changed after #53 will be merged. Surely, the readme will be updated accordingly.
We will make sure we mention you here to remind whenever #53 is merged and new version is released.

Thank you.

@abhijoshi2k yes, things look good. And yes, I've decided to switch from main to a version number after reconsidering my approach here. Thanks again 🙏🏽

@StevenJDH The feature you requested is now released with v2.0.0
You can now use it with separate config file. Documentation is available here

@abhijoshi2k perfect, I will upgrade today, thanks!