Getx: A better "what changed from X to Y" log

[joanofdart]

So basically right now, whenever there's a new version of GetX, we get some minimal information

It'd be a relief and a great help to everyone if we knew actually what changed, where. Kinda like what other libraries do with their development :)

[ghenry]

Can't GitHub do a lot of this for you to generate a change list?

On Sun, 9 Aug 2020, 16:28 Sebastian Montoya, [e-mail]
wrote:

So basically right now, whenever there's a new version of GetX, we get
some minimal information
[image: image]
https://user-images.githubusercontent.com/43426084/89735850-9683e600-da65-11ea-90cc-9f9a9f1fa533.png

It'd be a relief and a great help to everyone if we knew actually what
changed, where. Kinda like what other libraries do with their development :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jonataslaw/getx/issues/458, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABG66FJEPVXF2LOGVX4BETR726DDANCNFSM4PZHUI3Q
.

[joanofdart]

Of course you can go to the repo and do it, but it looks like the commits need to have some sort of structure. Take Bloc's commit history for example:

Is this a bad suggestion then @ghenry ?

[Nipodemos]

it would be nice if commitzen/commitlint did not needed node to use it...

for now @jonataslaw need to do manually.

[Nipodemos]

Of course you can go to the repo and do it, but it looks like the commits need to have some sort of structure. Take Bloc's commit history for example:

Is this a bad suggestion then @ghenry ?

how they do that? are they using node/npm to be able to use commitzen/commitlint/husky?
offtopic: @joanofdart loved you nickname, very clever 😄

[joanofdart]

@Nipodemos I was also looking into this doing some github actions myself and I do agree with you, its a pitty that we can't do it without node.

Now, to answer your other question, I think they do use commit analyzer and then an action to publish this changelog. I saw some packages that were aimed to leverage the usage of node (but its just some syntatic sugar/wrapper around node anyways).

And thanks! haha, I fell in love with it ever since I thought about it :D

[jonataslaw]

Whenever there is a substantial change, the changelog explains what has changed.
However, the most recent updates were bugfix updates (third item in semver 0.0.x), they are not break updates like the one you are mentioning in the bloc.
The print you posted has a small update that does not describe anything.
We are following semver, so you will only see detailed updates when features are added, or breaks.

[jonataslaw]

Here was a proposal to change changeLog, but due to old updates, this would become impossible, since GetX only became open source some time after its publication.
https://github.com/jonataslaw/getx/pull/60

[joanofdart]

@jonataslaw while I do see where you're coming from, I think some users do not know how to get the changes themselves or compare with a previous version.

The way I see it is that an user will see:

• "Fix individual imports"
  
  
  
  • Ah cool, which imports?
  
  
• "Fix language callback"
  
  
  
  • Which callback? which language?
  
  

And yeah I knew about that proposal (I've been following GetX for quite some time now! :), you're doing such a great job by the way).

Anyways, if this can't be done, then no worries, it was just a "hmm maybe this can be improved somehow".

[ghenry]

Isn't the simplest way to create an issue for anything. Close that in a
commit then when you do a tag, that's your changelog?

[jonataslaw]

Ok. These are structural issues, which do not affect you, and should not even be mentioned in changeLogs,
I do just to keep recurring updates, instead of accumulating changes to the new update.
I changed a folder, in an update, and the individual import from GetUtils / State Manager and I redid the structure so that it is present.
I don't think any library gives details of when changing the name or folder of an internal file, at least, I never saw it, but I could be wrong.

[jonataslaw]

Isn't the simplest way to create an issue for anything. Close that in a commit then when you do a tag, that's your changelog?

I can do that in the next updates

[ghenry]

Yeah, there's no point re-inventing something here. See what other popular
projects do, pick the way you like which works for you.

[jonataslaw]

Well, I think that is already resolved.
Closing.