2.0.3 -> 2.0.4 ?

[Maikuolan]

v2.0.3 was released 26th August 2018, and there's been numerous changes to the codebase since that time.

Given there was some new changes as recently as last week (renaming the default branch from master to main), maybe it would be worthwhile to create a new tag/release around now? @lablnet

[lablnet]

v2.0.3 was released 26th August 2018, and there's been numerous changes to the codebase since that time.

Given there was some new changes as recently as last week (renaming the default branch from master to main), maybe it would be worthwhile to create a new tag/release around now? @lablnet

Thanks for your concern, Let me tell you what I was thinking, your feedback will matter for me OfCouse. I was thinking to re-release Zest Framework from initial version 1.0.0, because in Past the framework was not stable at all, I have few things in my mind after which I will consider the framework stable, these things are as follow:

1. Security features (CSRF, XSS).
2. Package system (So, we can integrate any third party Database ORM)

What do you think?

[Maikuolan]

IMHO, there's nothing wrong with starting again. We learn from our work, discover things that work well, discover things that don't work well, and sometimes want to take a difference approach to our projects in the future. But, if starting again, I would recommend one of two options: Either (1) all tags/releases which already exist to continue to exist, and increment the major version for the restart (i.e., start again at v3.0.0), or, if really determined to start again at v1.0.0.. (2) give it a minor rebranding (e.g., NewZest? ReZest? NuZest..? Okay.. Those name ideas are actually kind of weak, and kind of suck a bit, and I'm not really sure what would be best insofar as names go.. but you get the point).

But, I would not recommend re-releasing a specific tag/version for a package when that particular package has already had an identical tag/version released in the past, under the exact same package name, because it can potentially cause confusion for some users, feels a little strange, and conversations in the future about the package.. when talking about such-and-such version, when there has been restarts, not just of the code, but also of the tags/versions/releases, participants in the conversation may need to ask to confirm.. "Are we talking about such-and-such from before, or from after the restart?"

Maybe other people will have different opinions, different views about this, and that's fine. Such things are subjective, and not an exact science. But at least, that's my opinions/views about it.

I had a similar situation with one of my own projects: phpMussel. (Actually.. I had this situation occur twice before for that particular project.. 👀 but everything has worked out in the end, so no worries). But.. talking about the second time it happened: For major versions 1 and 2, phpMussel existed as a single repository, and had its own integrated updater built into it, which I'd designed myself. But, for various reasons, I wanted to completely overhaul the entire package, use some different programming paradigms, split the package up into several different distinct repositories/packages (so, not all just as a single repository anymore), and rework it to be more oriented around Composer, rather than around its own updater (which I also consequently removed entirely, because its own updater wasn't quite compatible with the way Composer works). Because some of the new repositories/packages had the same/similar names as certain parts of the old repository, to avoid any ambiguity and potential confusion, I started those new repositories at v3, rather than going back to v1. (The old repository continues to exist, but as a metapackage, to orchestrate requirements/installations for the various packages which replace it for v3 onward). I probably could've just started at v1, and I guess, many other people would've done that, but seeing as I wasn't rebranding anything, I decided to continue with the existing line of tags/releases.

1. Security features (CSRF, XSS).
2. Package system (So, we can integrate any third party Database ORM)

Both of these things are good ideas. :-)

[lablnet]

@Maikuolan Thanks for great explainations and response. Yes we should stick with the version, so instead of v2.0.4, I think the point I mentioned after completing those we can launch v3.0.0 version.

[Maikuolan]

Sounds like a good plan. :+1:

[lablnet]

I just changed the name from Zest to AlphaZ Coz Zest framework is dead! should we consider it as successor of so called Zest and continue release cycles or from start.

What do you think @Maikuolan @peter279k

[peter279k]

Is the Zest be compatible with AlphaZ? I think it's okay to change name and keep Zest framework features.

[lablnet]

Is the Zest be compatible with AlphaZ? I think it's okay to change name and keep Zest framework features.

Yes OfCouse, the actual motive is that as this framework is not stable so it's useless to release 3.0.0 so I changed the name and we starts with 1.0.0

[peter279k]

Do you mark this abandoned? Please refer the documentation.

[lablnet]

Do you mark this abandoned? Please refer the documentation.

Not yet, because I lose my Google Authentactor data so I am unable to login to packageist there is no way to reset that! I've contact them Let's see when they reply me.