Jump to content
Latest News: (loading..)

Recommended Posts

I try to implement a rule for uploaded modules/apps and i thought of the following example:

App/Module version V1.0.0

Versioning is as: Major.Minor.Patch

Would that be suitable?
@tgely , @burt @kymation @raiwa @Tsimi @BrockleyJohn @frankl @Jack_mcs @multimixer  And everyone i forgotten.

Thoughts?

Share this post


Link to post
Share on other sites

Sounds good to me.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release here

Share this post


Link to post
Share on other sites
Posted (edited)

I try to figure out how to implement it?

First i was thinking to just let it increment on each update when the dev uploads a new .zip
Then i figure, that wont work

Now with above proposal i made arrives a new issue on server end.
It means on each new upload the developer must select via a radio-button:
This upload is a patch, a minor or a version.
so if he choose this is a patch the version becomes:
1.0.1
If he choose this is a minor:
1.1.0
if he after comes near:
1.0.9
What to do?
Just keep incrementing ???????
1.0.14 ????
Lol... it is kind of funny to find a correct solution.

What if the dev makes a 1.2.1 on his machine.
But the current state of the app on the market is 1.9.4 ????????

Or should i just read out the name of the zip?
 

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites
Posted (edited)

If the App is at 1.9.4 on a market...

Why would dev be making a 1.2.1 ?  The next iteration would be 1.9.5 OR 1.10.0 OR 2.0.0, no ?

Anyway, you have a minor problem to solve... osCommerce versioning, eg:

  • 2.3.1
  • 2.3.2
  • 2.3.3
  • 2.3.3.1
  • 2.3.3.2
  • 2.3.3.3
  • 2.3.3.4
  • 2.3.4
  • 2.3.4.1
  • 2.3.5 (ha)
  • 2.3.6 (haha)
  • 2.4 (lol)

Which going by some standard appears to be;

major.something.minor.patch

Edited by burt

This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest current code (community-supported responsive 2.3.4.1BS Edge) here

 

Share this post


Link to post
Share on other sites

@burt  i was thinking before i made this post exact same.

But that doesn't seem the correct way.
I investigated a little and found that when use versioning. the dot-seperated values represent a particular status.
In my proposed case:
Major (like a new release, could be completely new approach? )
Minor (like a module before based on jquery-ui, now becomes based on bootstrap)
Patch (patches/hot-fixes on the current active build)

I not persé say must/should be like that.
But that is why i ask opinions.

But indeed, i thought same like you before.

Share this post


Link to post
Share on other sites

What are these for? Is it just for internal convention or to be used actively somehow?

There are usually some "rules" (basically meanings) behind the convention adopted, which help you decide what kind of verison you're creating like

  • no new function or design in a patch
  • no breaking change in a minor release

Is it also to map dependencies - this version of this only works with that version of that?

Maybe composer's point of view is a good place to start if so:

https://getcomposer.org/doc/articles/versions.md

I haven't looked at them carefully but the oscommerce.json files in 2.4 look just like composer.json files to me.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

 

For Github users: Bootstrap addons - one per branch - https://github.com/BrockleyJohn/Responsive-osCommerce/wiki/Overview-of-Branches

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
1 hour ago, wHiTeHaT said:

if he after comes near:
1.0.9
What to do?
Just keep incrementing ???????
1.0.14 ????

This.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release here

Share this post


Link to post
Share on other sites
3 hours ago, wHiTeHaT said:

Versioning is as: Major.Minor.Patch

That would be my vote. But are you able to control this? I thought Harald was the only one that could do that. If you can do it, how will you enforce it? So if you say the first version of all addons should be 1.0 and I decide I want mine to be 11.3, will I not be able to upload my addon? What happens to all of the existing addons?

Share this post


Link to post
Share on other sites
9 minutes ago, BrockleyJohn said:

What are these for? Is it just for internal convention or to be used actively somehow?

@BrockleyJohn 
Yes it is ment for active usage to update market add-ons.
I'm very busy at the moment setting up a market place where can install on-the-fly add-ons just by pushing a button (like Wordpress).

And i can GUARANTEE it works.
I would like to offer (just a little but mature) a better way of maintaining installed apps.
Yet, also guideline developers on "how-to" offering add-ons.
That is just a must, still giving them the freedom to do what they want.
But let them respect osCommerce core.
No problem when make an app what goes around the core, but just keep everything working for all.
Apps should be as easy to un-install as when you installed them ... right?

So... the point of the post is...
How to let Developers maintain their submitted add-ons/apps any Code?
What would be a good practice?

I'm open for anything.
 

Share this post


Link to post
Share on other sites
Posted (edited)

@Jack_mcs i would like to do that via a market add-on build in to the osCommerce backend.
I made some promising results:



Additional video showcasing the market-place's website (the apps you see here will be brows-able the exact same inside the market add-on, just instead of downloading, they will be/can be installed, depending on the store owners choice) :

 

Thoughts ........... more then welcome :thumbsup:

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites
16 minutes ago, wHiTeHaT said:

Thoughts ........... more then welcome :thumbsup:

If you are building a new marketplace ... I would like to be able to see screen shots (where applicable) of an app before I download it.


If you are running the "official" osC 2.3.4 or 2.3.4.1 download, your installation is obsolete! Get the latest community-supported responsive "Edge" release here

Share this post


Link to post
Share on other sites

@wHiTeHaT in that case I suggest you go with the composer approach for numbering, along with a json file that defines at a minimum the addon name, author, addon version, applicable version and can be expanded to add namespaces if used and dependencies on other addons if they exist


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

 

For Github users: Bootstrap addons - one per branch - https://github.com/BrockleyJohn/Responsive-osCommerce/wiki/Overview-of-Branches

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
Posted (edited)
7 minutes ago, BrockleyJohn said:

@wHiTeHaT in that case I suggest you go with the composer approach for numbering, along with a json file that defines at a minimum the addon name, author, addon version, applicable version and can be expanded to add namespaces if used and dependencies on other addons if they exist

It would might be the best approach.
I was try to keep it more low-level, so it would be more easier.

But the heck!!!!!!!
Why not.
[For that i have to extract the contents of the archive first. And a developer needs to provide all that within the uploaded archive]

If that is applicable, if the active dev's can.. and mostly "want to" maintain it like that........ i'm all in.
  

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites

If going to use @BrockleyJohn proposal.
Developers keep in mind....
You have to follow a strict guideline when you going to submit an app to the market-place.
-A .json
-A changelog (probably a .ini)  kind of like (in ascending  by date) :
     [ v4.0.1  2018-05-04]
        - replaced db statements
        - common fixes
     [ v3.5.4  2018-01-26]
        - OSCOM namespaces
        - start using fontawesome 5 icons
        - Bootstrap 4.1.0 HTML

 
-The actual package content as :
    -catalog/(catalog files)
    -admin/ (admin files)

 

All that info WILL be available in the market's download page + in the market's add-on running in your store's admin.

Thoughts?

 

Share this post


Link to post
Share on other sites

They don't need to create the json themselves, it's just a representation of info that you make them fill in on a form; if the file's present parse it into the form instead.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

 

For Github users: Bootstrap addons - one per branch - https://github.com/BrockleyJohn/Responsive-osCommerce/wiki/Overview-of-Branches

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
Posted (edited)

My personal idea was:
Use a form:
Provide App/Module Name (cannot be changed after)
No version need, each start as V1.0.0
Provide Demo images/video.

That's it for the FIRST upload of a package.

When go update:
Name stay as is.
Version based on selected Radio-button will be incremented as selected:
This package is a patch...
So just LAST will be incremented automatic.
1.0.1
The package is a MINOR. 
Patch becomes 0
Minor field (the middle one) increments by 1
so: 1.1.0

For a Main version.
Minor become 0, patch become 0
Main becomes:
2.0.0
 

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites
Posted (edited)
13 minutes ago, BrockleyJohn said:

They don't need to create the json themselves, it's just a representation of info that you make them fill in on a form; if the file's present parse it into the form instead.

For what i require a json then?
I not say it is wrong.
But can read out a json or a .ini or even just a .txt
A .json is commonly not used for this kind of purposes.
There is no rule in that, sure it can.

(lol, ashole... now i need to learn .json formating, i just figured out .ini's haha)

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites
Posted (edited)

but: 

 

 

Regardless of "extra".
I figured out there is no extra files required.
When you update the app, you only have to paste/update the change-log content.
Like that developer only need to provide:
- catalog files
- admin files
- *optional installer. like :
Class Installer(){

method install(){

/*your installer rules*/

}

}

*** Keep in mind there will be also an option to use an installer what is called after the extraction of the archive content.
The market add-on does not require to "Load" an external file for a change Log.
It is part of the add-on's " content.
just like a title.
just like an image.


 

Edited by wHiTeHaT

Share this post


Link to post
Share on other sites

Where I'm coming from with the json stuff is the shopowner end. It's a codification of the installed addon and supports:

You give them an addon dashboard which tells them about available updates and compatibility with their base version, with potential impacts and one-click updates. You upsell/cross-sell further purchases from the marketplace based on their installed ones - stuff from the same developer, stuff for the same kind of store, additional payment methods...


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

 

For Github users: Bootstrap addons - one per branch - https://github.com/BrockleyJohn/Responsive-osCommerce/wiki/Overview-of-Branches

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites
3 hours ago, BrockleyJohn said:

You give them an addon dashboard which tells them about available updates and compatibility with their base version, with potential impacts and one-click updates. You upsell/cross-sell further purchases from the marketplace based on their installed ones - stuff from the same developer, stuff for the same kind of store, additional payment methods...

Yep, these parts are already prepared, however for it it not require an additional file to manage/control these parts.

Share this post


Link to post
Share on other sites
20 hours ago, wHiTeHaT said:

Versioning is as: Major.Minor.Patch

I'm not really clear on what you're doing but for what it's worth, would it be useful to add Security Patch?

Dan

Share this post


Link to post
Share on other sites

Not really @Dan Cole , a patch can be anything, even a security fix.

Such would then be mentioned in the "Change Log" perhaps something like:

     [ v4.0.2  2018-05-05]
        - security fixes

     [ v4.0.1  2018-05-04]
        - replaced db statements
        - common fixes
     [ v3.5.4  2018-01-26]
        - OSCOM namespaces
        - start using fontawesome 5 icons
        - Bootstrap 4.1.0 HTML

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×